A congestion control method and device for real-time communication

Abstract

The embodiment of the present application provides a congestion control method and device for real-time communication. The technical scheme provided by the embodiment of the present application enters a code rate restriction state according to a set code rate restriction period when network congestion is detected, determines a current restriction code rate according to a historical restriction code rate and a maximum receiving code rate of a data receiving end when network congestion occurs, and performs network congestion control based on the current restriction code rate in the code rate restriction state, wherein the detection code rate enters a detection state after the duration of network congestion reaches a set detection waiting time or after each code rate restriction period, and the detection code rate is obtained by upward detection of the code rate in the detection state. The network congestion control is performed based on the current restriction code rate in the code rate restriction period. While ensuring that the code rate is close to the code rate restriction under the current network environment, the number of upward detection of the code rate is effectively reduced, the code rate fluctuation caused by frequent upward detection of the code rate is reduced, and the quality of experience of real-time communication of a user is improved.

Description

Technical Field

[0001] This application relates to the field of audio and video technology, and in particular to a congestion control method and apparatus for real-time communication. Background Technology

[0002] With the development of network and audio / video technologies, real-time communication applications have received better technical support, and real-time communication has higher requirements for data transmission latency, throughput, and packet loss. To ensure the quality of user experience, congestion control algorithms suitable for real-time communication scenarios are generally used to control audio and video transmission, such as controlling the encoding bitrate at the data sending end.

[0003] Existing congestion control algorithms typically rely on periodic bitrate prediction mechanisms to improve throughput. However, in real-time communication, when user network quality is poor, the bottleneck in the data transmission path is relatively low. This periodic bitrate spike can easily cause the bitrate to exceed the link's processing capacity, resulting in significant bitrate fluctuations within a short period and impacting the user's real-time communication experience. Summary of the Invention

[0004] This application provides a congestion control method and apparatus for real-time communication to solve the technical problem in related technologies where periodic bit rate spikes can easily lead to bit rate exceeding the link's processing capacity, causing large fluctuations in bit rate within a short period of time, thus affecting the user's real-time communication experience quality. This method effectively reduces bit rate fluctuations and improves the user's real-time communication experience quality.

[0005] In a first aspect, embodiments of this application provide a congestion control method for real-time communication, comprising:

[0006] Determine the rate limiting period when network congestion is detected;

[0007] The current limiting bit rate is determined based on the historical limiting bit rate and the maximum receiving bit rate at the data receiver during network congestion.

[0008] Encoding processing is performed based on the current limited bit rate within the set detection waiting time;

[0009] After the probe waiting time, encoding processing is performed based on the probe bit rate, which is obtained when the duration of network congestion reaches the set probe waiting time, or after each bit rate limiting cycle.

[0010] In a second aspect, embodiments of this application provide a congestion control device for real-time communication, including a period determination module, a bit rate determination module, a first encoding module, and a second encoding module, wherein:

[0011] The period determination module is configured to determine the bit rate limiting period when network congestion is detected.

[0012] The bit rate determination module is configured to determine the current bit rate based on the historical bit rate limit and the maximum received bit rate of the data receiver when network congestion occurs.

[0013] The first encoding module is configured to perform encoding processing based on the current limited bit rate within a set detection waiting time;

[0014] The second encoding module is configured to perform encoding processing based on the probe code rate after the probe waiting time, wherein the probe code rate is obtained when the duration of network congestion reaches the set probe waiting time, or after each of the code rate limiting cycles.

[0015] In a third aspect, embodiments of this application provide a congestion control device for real-time communication, comprising: a memory and one or more processors;

[0016] The memory is used to store one or more programs;

[0017] When the one or more programs are executed by the one or more processors, the one or more processors implement the congestion control method for real-time communication as described in the first aspect.

[0018] In a fourth aspect, embodiments of this application provide a non-volatile storage medium for storing computer-executable instructions, which, when executed by a computer processor, are used to perform a congestion control method for real-time communication as described in the first aspect.

[0019] In a fifth aspect, embodiments of this application provide a computer program product comprising a computer program stored in a computer-readable storage medium, wherein at least one processor of the device reads from the computer-readable storage medium and executes the computer program, causing the device to perform the congestion control method for real-time communication as described in the first aspect.

[0020] This application embodiment enters a rate-limiting state according to a set rate-limiting period when network congestion is detected. The current rate-limiting bitrate is determined based on the historical rate-limiting bitrate and the maximum received bitrate at the data receiver when network congestion occurs. Network congestion control is performed based on the current rate-limiting bitrate in the rate-limiting state. The probe bitrate is obtained by probing the bitrate when the duration of network congestion reaches a set probe waiting time, or by probing the bitrate after each rate-limiting period. Network congestion control is performed based on the current rate-limiting bitrate within the rate-limiting period. This approach ensures that the bitrate is close to the rate limit in the current network environment while effectively reducing the number of rate probing attempts, thus reducing bitrate fluctuations caused by frequent rate probing attempts and improving the user's real-time communication experience. Attached Figure Description

[0021] Figure 1 This is a flowchart of a congestion control method for real-time communication provided in an embodiment of this application;

[0022] Figure 2 This is a schematic diagram of a limited bit rate determination process provided in an embodiment of this application;

[0023] Figure 3 This is a flowchart of another congestion control method for real-time communication provided in an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of a packet loss network congestion detection process provided in an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of a latency network congestion detection process provided in an embodiment of this application;

[0026] Figure 6 This is a schematic diagram of the structure of a congestion control device for real-time communication provided in an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of the structure of a real-time communication congestion control device provided in an embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but additional steps not included in the drawings may also be present. The above processes can correspond to methods, functions, procedures, subroutines, subroutines, etc.

[0029] The congestion control method for real-time communication provided in this application can be applied to real-time communication scenarios in social networks. It aims to control network congestion based on the current limited bitrate within a bitrate-limited period. Bitrate probing is performed when the duration of network congestion reaches a set probing wait time, or after each bitrate-limited period. This ensures the bitrate is close to the bitrate limit under the current network environment while effectively reducing the number of bitrate probes, minimizing bitrate fluctuations caused by frequent probes, and improving the user's real-time communication experience. In existing congestion control schemes, such as BBR (Bottleneck Bandwidth and Round-trip time) based congestion control algorithms, a bitrate prediction mechanism is typically designed for periodic probing to improve throughput. However, when the user's network quality is poor and the link bottleneck is low, frequent periodic probing can easily cause the bitrate to exceed the link's processing capacity, leading to network congestion, packet loss and retransmission, and affecting the user's call experience. Based on this, an embodiment of the present application provides a congestion control method for real-time communication to solve the technical problem that frequent bit rate increases in existing congestion control schemes lead to bit rate fluctuations, affecting the user's real-time communication experience quality.

[0030] Figure 1 A flowchart of a real-time communication congestion control method provided in an embodiment of this application is given. The real-time communication congestion control method provided in this embodiment of the application can be executed by a real-time communication congestion control device, which can be implemented by hardware and / or software and integrated into a real-time communication congestion control equipment.

[0031] The following description uses a real-time communication congestion control device as an example to illustrate the congestion control method for real-time communication. (Reference) Figure 1The congestion control method for this real-time communication includes:

[0032] S110: Determine the rate limiting period when network congestion is detected.

[0033] The congestion control device provided in this solution can be used as a data transmitter in a real-time call scenario. The encoding system configured in the congestion control device encodes audio and video data according to a determined bitrate to obtain call data, and then sends the call data to the data receiver via a server. After receiving the call data, the data receiver can return acknowledgment information (ACK information) to the congestion control device through the server. The congestion control device can determine the reception status of the call data by the data receiver based on the acknowledgment information.

[0034] For example, during real-time communication, network conditions are monitored in real time to determine whether network congestion has occurred, and if network congestion is detected, the applicable bitrate limiting period for the current real-time call network environment is determined.

[0035] Upon detecting network congestion or after determining a rate limiting period, the congestion control device enters a rate limiting state. If no new network congestion is detected within the rate limiting period after entering this state, the current rate limiting state ends. If new network congestion is detected within the rate limiting period, a new rate limiting period is determined based on the newly detected congestion, and a new rate limiting state is entered based on this new period. Under rate limiting conditions, the congestion control device will limit the number or frequency of rate-to-rate increases.

[0036] It needs to be explained that when the congestion control device enters the bitrate limiting state, it can stop periodically probing the bitrate within a bitrate limiting period. This reduces the risk of network congestion caused by frequent periodic probing when the real-time communication network is already close to its bottleneck. Furthermore, under the influence of some congestion backoff strategies, the bitrate may fluctuate significantly in a short period of time, affecting the user experience.

[0037] In one embodiment, when the congestion control method for real-time communication provided by this solution determines the rate limiting period in the event of network congestion, the rate limiting period may be determined based on a set limiting period, historical limiting rates, and the maximum received rate of the data receiver when network congestion occurs.

[0038] For example, when network congestion is detected, the maximum receive bit rate at the data receiver during the congestion is determined, and the current bit rate limiting period is determined based on this maximum receive bit rate, historical limit bit rates, and a set limiting period. For instance, the set limiting period is adjusted based on a comparison of the maximum receive bit rate and historical limit bit rates to dynamically determine the bit rate limiting period corresponding to the current network congestion state.

[0039] The historical limit code rate is the limit code rate determined in the previous congestion control process, and the current limit code rate determined in the current congestion control process will be used as the historical limit code rate for subsequent congestion control processes.

[0040] In one embodiment, the maximum received bit rate of the data receiver when network congestion occurs can be determined based on the received bit rate corresponding to multiple sampling windows within a set time period. For example, multiple sampling windows are determined according to a set window size and step size. In each sampling window, multiple acknowledgment messages (ACK messages) of the corresponding time length are collected from the data receiver, and the received bit rate corresponding to each sampling window is determined according to the acknowledgment messages. The maximum received bit rate is determined as the maximum received bit rate of the data receiver when network congestion occurs.

[0041] This solution dynamically determines the bitrate limiting period applicable to the current network condition based on the set limiting period, historical limiting bitrate, and maximum received bitrate. It dynamically adjusts the duration of bitrate increase, ensuring bitrate stability while timely increasing bitrate to improve audio and video encoding quality and fully utilize network bandwidth resources.

[0042] In one possible embodiment, the congestion control method for real-time communication provided by this solution, when determining the rate limiting period based on a set limiting period, historical rate limiting, and the maximum received rate of the data receiver when network congestion occurs, may be:

[0043] S111: When network congestion occurs, if the difference between the maximum received bit rate of the data receiver and the historical limit bit rate is less than the first threshold, the set limit period is increased to obtain the bit rate limit period.

[0044] S112: When network congestion occurs, if the difference between the maximum received bit rate of the data receiver and the historical limited bit rate is between the first threshold and the second threshold, the set limiting period is reduced to obtain the bit rate limiting period, where the second threshold is greater than the first threshold.

[0045] S113: When network congestion occurs, if the difference between the maximum received bit rate of the data receiver and the historical limit bit rate is greater than the second threshold, the set limit period is adjusted to the set minimum period to obtain the bit rate limit period.

[0046] For example, when network congestion is detected, the maximum received bit rate and the historical limit bit rate at the data receiver when network congestion occurs are determined. The maximum received bit rate and the historical limit bit rate are compared, and the current bit rate limit period is dynamically adjusted based on the comparison result. For example, the difference between the maximum received bit rate and the historical limit bit rate is calculated, and the set limit period is dynamically adjusted based on the range corresponding to the difference to obtain the bit rate limit period.

[0047] When the difference between the maximum received bit rate and the historical limit bit rate is less than a set first threshold, the limit bit rate determined in the current congestion control process (the limit bit rate can be determined before, after, or simultaneously with the determination of the bit rate limiting period) is considered more suitable for the current network state. Therefore, the set limiting period is increased to obtain the bit rate limiting period, thus maintaining the bit rate limiting state for a longer time. Optionally, increasing the set limiting period can be achieved by multiplying the set first multiple with the set limiting period, and using the result of the multiplication as the bit rate limiting period.

[0048] When the difference between the maximum received bit rate and the historical limit bit rate falls between a first threshold and a second threshold, the reliability of the limit bit rate determined in the current congestion control process is considered low. Therefore, the setting limit period is reduced to obtain the bit rate limit period, shortening the duration of the bit rate limit state and providing more opportunities for bit rate increases. The second threshold is greater than the first threshold. Optionally, reducing the setting limit period to obtain the bit rate limit period can be achieved by dividing the setting limit period by a second multiple, using the result of the division as the bit rate limit period.

[0049] When the difference between the maximum received bitrate and the historical limit bitrate is greater than the second threshold, it can be considered that the current network has changed significantly. At this time, the network fluctuates greatly and is not suitable for maintaining a ceiling state for a long time. Therefore, the setting limit period is adjusted to the setting minimum period to obtain the bitrate limit period.

[0050] This solution dynamically determines the bitrate limiting period by comparing the difference between the maximum received bitrate and the historical limited bitrate with the first threshold and the second threshold. It dynamically balances the duration of the bitrate limit and the number and frequency of bitrate increases, ensuring bitrate stability while timely increasing the bitrate to improve the encoding quality of audio and video and making full use of network bandwidth resources.

[0051] S120: Determine the current limiting bit rate based on the historical limiting bit rate and the maximum receive bit rate of the data receiver when network congestion occurs.

[0052] For example, when network congestion is detected and a rate-limited state is entered, the current rate-limited bitrate is determined based on the historical rate-limited bitrate and the maximum received bitrate at the data receiver during the network congestion. Optionally, the current rate-limited bitrate can be obtained by performing a moving average of one or more historical rate-limited bitrates most recent to the current time and the maximum received bitrate, according to a set weighting coefficient.

[0053] In one possible embodiment, such as Figure 2 As shown in the schematic diagram of the limiting bit rate determination process, the congestion control method for real-time communication provided in this solution, when determining the current limiting bit rate based on historical limiting bit rates and the maximum received bit rate at the data receiver during network congestion, can be as follows:

[0054] S121: Determine the first code rate based on the maximum received code rate of the data receiver and the set code rate coefficient when network congestion occurs.

[0055] S122: Based on the set weight coefficient, perform a moving average process on the first bitrate and the historical limit bitrate to obtain the current limit bitrate.

[0056] For example, the first bitrate is obtained by multiplying the maximum received bitrate at the data receiver during network congestion by a set bitrate coefficient. After determining the first bitrate, a moving average is performed on the first bitrate and historical limit bitrates according to a set weighting coefficient to obtain the current limit bitrate. The moving average can be performed on one or more historical limit bitrates most recent to the current time.

[0057] This solution provides a bitrate coefficient less than 1. This coefficient can be used to attenuate the maximum received bitrate before determining the current limiting bitrate. Since the real-time communication network may be experiencing network congestion and entering a bitrate-limited state, the current maximum received bitrate could trigger further congestion. This solution multiplies the maximum received bitrate by the coefficient, reserving some bandwidth capacity while maximizing bandwidth, thus improving network data transmission capabilities and user experience. Furthermore, this solution uses a moving average of the initial bitrate and historical limiting bitrates to reduce the impact of sudden changes in the limiting bitrate on audio and video encoding quality. This results in smoother transitions in audio and video encoding quality, reducing user discomfort caused by abrupt changes in playback quality and improving the user experience.

[0058] S130: Encode the code based on the current limited bit rate within the set detection waiting time.

[0059] S140: After the probe waiting time, encoding is performed based on the probe bit rate. The probe bit rate is obtained when the duration of network congestion reaches the set probe waiting time, or after each bit rate limiting cycle.

[0060] The probe waiting time provided in this solution can be understood as the time to wait for the first bitrate increase after network congestion is detected. The first bitrate increase is performed when the duration of network congestion reaches the set probe waiting time. In one embodiment, the bitrate limiting period provided in this solution is longer than the probe waiting time.

[0061] For example, the encoding system configured in the real-time communication congestion control device sends the aforementioned determined current limit bitrate, or the probe bitrate obtained after a set probe waiting time, to the encoding system. Upon receiving the current limit bitrate, the encoding system performs encoding processing based on the received current limit bitrate within the set probe waiting time, and the probe bitrate received after the set probe waiting time. When performing audio and video encoding processing, the encoding system can determine the encoding bitrate according to a pre-configured bitrate control strategy, using the received current limit bitrate or probe bitrate as the limit for the maximum encoding bitrate, ensuring that the encoding bitrate of the transmitted call data is within the current limit bitrate or probe bitrate.

[0062] In one embodiment, after detecting network congestion and entering a rate-limited state, the encoding system performs encoding based on a determined current rate-limited bitrate before attempting a rate ramp. After a rate ramp, the encoding system performs encoding based on the probe bitrate determined by the ramp. Upon detecting new network congestion, a new rate-limited state is entered, and the encoding system performs encoding based on a newly determined current rate-limited bitrate until a new probe bitrate is determined or new network congestion is detected again.

[0063] The probe bitrate provided by this solution is obtained either when the duration of network congestion reaches a set probe waiting time, or after each bitrate limiting cycle, through bitrate upprobing. For example, after each network congestion detection, it is determined whether the duration of the network congestion (the time elapsed since the detection) has reached the set probe waiting time, or whether the time interval since the last bitrate upprobing has reached the bitrate limiting cycle. If the duration of the network congestion reaches the set probe waiting time, or the time interval since the last bitrate upprobing has reached the bitrate limiting cycle, then bitrate upprobing is performed to obtain the probe bitrate. The upprobing amplitude can be adjusted based on the number of consecutive probe entries; the more consecutive probe entries, the larger the upprobing amplitude. Furthermore, the number of consecutive probe entries is reset to zero when new network congestion is detected.

[0064] The above describes a method that, upon detecting network congestion, enters a rate-limiting state based on a set rate-limiting period. The current rate-limiting bitrate is determined based on historical rate-limiting bitrates and the maximum received bitrate at the data receiver during network congestion. Network congestion control is then performed based on this current rate-limiting bitrate. The probe bitrate is obtained by probing the bitrate when the duration of network congestion reaches a set probe waiting time, or by probing the bitrate after each rate-limiting period. Within the rate-limiting period, network congestion control is performed based on the current rate-limiting bitrate. This approach ensures the bitrate is close to the rate limit under the current network environment while effectively reducing the number of rate probes, minimizing bitrate fluctuations caused by frequent probes, and improving the user's real-time communication experience.

[0065] Based on the above embodiments, Figure 3 A flowchart of another congestion control method for real-time communication provided in an embodiment of this application is given. This congestion control method for real-time communication is a concretization of the above-described congestion control method for real-time communication. (Reference) Figure 3 The congestion control method for this real-time communication includes:

[0066] S210: Determine the rate limiting period when network congestion is detected.

[0067] S220: Determine the current limiting bit rate based on the historical limiting bit rate and the maximum receiving bit rate of the data receiver when network congestion occurs.

[0068] S230: Encode the code based on the current limited bit rate within the set detection waiting time.

[0069] S240: After the probe waiting time, encoding is performed based on the probe bit rate. The probe bit rate is obtained when the duration of network congestion reaches the set probe waiting time, or after each bit rate limiting cycle.

[0070] S250: When the duration of network congestion reaches the set probe waiting time, or when the time interval since the last rate increase reaches the rate limit period, a rate increase is performed to obtain the probe rate.

[0071] For example, after each network congestion is detected, the duration of the network congestion and the time interval between the current time and the last bitrate spike are continuously recorded. It is determined whether the duration of the network congestion has reached a set probe waiting time. Upon first determining that the duration of the network congestion has reached the set probe waiting time after each occurrence of network congestion, a probe state is entered, and a bitrate spike is performed in the probe state to obtain the probe bitrate.

[0072] If the duration of network congestion does not reach the set probe wait time, or if the duration of network congestion reaches the set probe wait time but is not the first time the set probe wait time has been reached, it is determined whether the time interval since the last bitrate attempt has reached the bitrate limiting period. If the time interval since the last bitrate attempt has reached the bitrate limiting period, the system enters probe mode and performs bitrate attempts to obtain the probe bitrate. That is, after performing one bitrate attempt during the probe wait time for network congestion detection, continuous bitrate attempts are performed according to the bitrate limiting period.

[0073] In one embodiment, during a rate-limited state, if the time interval since the last rate increase has not reached the rate-limiting period, the maximum value between the current estimated bitrate and the current limited bitrate determined by the encoding system during the encoding process can be used as the probe bitrate and provided to the encoding system. The encoding system adjusts the current limited bitrate according to a pre-configured rate control strategy to obtain the current estimated bitrate.

[0074] Specifically, the first instance of network congestion reaching the set detection wait time is defined as the duration of network congestion reaching the set detection wait time. That is, the detection state is initiated when the duration of network congestion first reaches the set detection wait time after congestion occurs; subsequent instances of the set detection wait time not triggering the detection state. At this point, within the rate-limiting period, a rate spike is performed when the detection wait time is first reached; no further rate spikes are performed within the rate-limiting period. After the rate-limiting period, a rate spike is performed each time the time interval between the previous rate spike and the previous rate spike reaches the rate-limiting period.

[0075] This solution attempts to acquire more network bandwidth for data transmission by probing the bitrate when network congestion lasts for a set probe wait time or when the time interval since the last bitrate spike reaches the bitrate limit period. The current bitrate limit serves as the upper limit for bitrate growth during encoding, maximizing bandwidth utilization while alleviating network congestion. This means the current bitrate limit is assumed to be sustainable over a long period (the bitrate limit period). However, because the encoding bitrate decreases after congestion, a short probe wait time is needed to quickly attempt to spike the bitrate and approach the current limit. Once the network recovers, the bitrate is restored to a stable and relatively high level as soon as possible, and periodic bitrate spikes are performed according to the bitrate limit period. This effectively reduces network drops caused by prolonged periods without bitrate spikes, improving network congestion control quality and enhancing user experience.

[0076] In one possible embodiment, the congestion control method for real-time communication provided by this solution, when obtaining the probed bit rate through bit rate probing, can be:

[0077] S251: If the time interval between the last bitrate increase and the last bitrate increase reaches the set detection time interval, the detection bitrate is obtained by increasing the bitrate based on the current limit bitrate or the historical detection bitrate.

[0078] S252: If the time interval since the last rate increase is less than the set detection time interval, determine the detection rate based on the current estimated rate and the current limit rate.

[0079] For example, after entering the probing state, it is determined whether the time interval between the current time and the last bitrate increase reaches the set probing time interval. If the time interval between the current time and the last bitrate increase reaches the set probing time interval, the probing bitrate is obtained by increasing the bitrate based on the current limit bitrate or the historical probing bitrate. If the time interval between the current time and the last bitrate increase is less than the set probing time interval, the probing bitrate is determined based on the historical limit bitrate and the current limit bitrate.

[0080] Specifically, when probing upwards to obtain the probe bitrate based on the current limited bitrate or historical probe bitrate, if this is the first time entering the probe state for bitrate probing, the probe bitrate can be obtained based on the current limited bitrate. Subsequent probes can be based on historical probe bitrates. Optionally, when determining the probe bitrate based on the current estimated bitrate and the current limited bitrate, the maximum value between the two can be used as the probe bitrate for this current bitrate probing. This scheme determines the corresponding probe bitrate by considering whether a probe time interval is set based on the time interval since the last bitrate probing, allowing the network sufficient time to clear out congestion and quickly restoring the bitrate to a stable and relatively high level after network recovery, thereby improving network congestion control quality and enhancing user experience.

[0081] In one possible embodiment, the congestion control method for real-time communication provided by this solution, when obtaining the probed bitrate by probing upwards based on the current limited bitrate or historical probed bitrate, can be:

[0082] S2511: Determine the probe factor based on the number of consecutive rate probes.

[0083] S2512: The probe rate is obtained by probing upwards based on the probe factor and the current limit bit rate or historical probe bit rate.

[0084] For example, when the time interval since the last bitrate spike reaches a set detection time interval, a detection factor is determined based on the current number of consecutive bitrate spikes. The greater the number of consecutive bitrate spikes, the larger the corresponding detection factor. The detection factor is positively correlated with the spike amplitude.

[0085] In one embodiment, after determining the probe factor, the probe bitrate is obtained by probing upwards based on the probe factor and the current limit bitrate or historical probe bitrate. Specifically, when initially entering the probe state for bitrate probing, the probe bitrate can be obtained by probing upwards based on the probe factor and the current limit bitrate. Subsequent entries into the probe state for bitrate probing can be obtained by probing upwards based on the probe factor and historical probe bitrate. This scheme determines the probe factor based on the number of consecutive bitrate probing attempts, and accurately determines the probe bitrate by probing upwards based on the probe factor and the current limit bitrate or historical probe bitrate. A higher number of consecutive bitrate probing attempts corresponds to a higher probe factor and a larger upward probe magnitude, allowing the bitrate to recover to a stable and higher level more quickly, improving network congestion control quality and enhancing user experience.

[0086] In one possible embodiment, the detection factor provided by this solution can be determined based on the following detection factor determination formula:

[0087] F probe =min((I probe / 2+1)*10,20)

[0088] Among them, F probe As the detection factor, I probe This represents the number of consecutive attempts to increase the bit rate.

[0089] In one possible embodiment, the probe rate provided by this scheme can be determined based on the following probe rate determination formula:

[0090] R = min(R) max R2 probe )

[0091] R max =max(R) rm *1.5, R rm +300)

[0092] R2 probe =max(R1) probe +20, R1 probe *(1+F probe / 100)

[0093] R1 probe=max(R) last *1.3, R last +20)

[0094] Where R is the probe code rate, R rm R represents the maximum receive bit rate at the data receiver during network congestion. last For historically limited bitrates, R max Based on the maximum received code rate R rm The determined first candidate code rate, R last For historical probe bitrate, when entering the probe state for the first time to probe the bitrate, R last For the current limited bitrate, R1 probe For the current limited bit rate or historical probe bit rate R last Determined intermediate bitrate, R2 probe For intermediate bit rate R1 probe The determined second candidate bitrate. The intermediate bitrate can be calculated when entering the probing state (i.e., after a bitrate limit period without bitrate increase), or when the time interval since the last bitrate increase reaches a set probing interval. This scheme determines the probing factor using a probing factor determination formula and the probing bitrate using a probing bitrate determination formula, thereby improving network congestion control quality more accurately and efficiently, and enhancing user experience.

[0095] In one possible embodiment, the congestion control method for real-time communication provided by this solution, before determining the rate limiting period upon detecting network congestion, can determine whether network congestion has occurred based on the packet loss rate and latency jitter during real-time call network data transmission. Optionally, packet loss-based congestion detection and latency jitter-based congestion detection can divide time windows of different lengths and establish baseline packet loss rates or latency jitter under different time windows, and identify whether network congestion has occurred according to the actual scenario type. The scenario type can be set by different packet loss rates under different time lengths, or it can be set by different inherent packet loss rates of different links under different time lengths determined through comparative learning.

[0096] Network congestion based on packet loss can be judged by considering both random packet loss and congestion-related packet loss. Random packet loss can be considered an inherent attribute of the link itself, related to link quality, and its occurrence is unpredictable, but its overall probability of occurrence can be quantified, i.e., the baseline packet loss rate. Based on this, in judging network congestion based on packet loss, the baseline packet loss rate can be compared with the current packet loss rate. By determining whether the difference between the two is within a tolerable threshold range, it can be used as a standard to determine whether network congestion based on packet loss has occurred.

[0097] In one possible embodiment, such as Figure 4As shown in the schematic diagram of a packet loss network congestion detection process, the congestion control method for real-time communication provided in this solution, before determining the rate limiting period upon detecting network congestion, also includes:

[0098] S201: Determine a first baseline packet loss rate based on the first quantile packet loss rate over a first time length, and determine the packet loss rate variance and the second baseline packet loss rate based on the average packet loss rate over a second time length, wherein the first time length is greater than the second time length.

[0099] S202: Determine the current packet loss rate, the first average packet loss rate in the third time length, and the second average packet loss rate in the fourth time length, where the fourth time length is greater than the third time length.

[0100] S203: Based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the packet loss rate variance, the first average packet loss rate, and the second average packet loss rate, determine whether packet loss-based network congestion has occurred.

[0101] In one embodiment, multiple sampling windows can be set, and the packet loss rate corresponding to each sampling window is used to determine whether packet loss-based network congestion has occurred. Optionally, sampling windows of different sizes can be divided according to the current bitrate range. A higher bitrate indicates a richer amount of data from recent user communication, resulting in more accurate network data measurements. Therefore, only a smaller window of data is needed as input to the detection mechanism, allowing for a smaller sampling window. Conversely, a lower bitrate indicates a bottleneck in recent user communication, leading to fewer network status updates. Therefore, a larger sampling window of data is needed as input for congestion detection. After determining the multiple sampling windows and their sizes, the data transmission and reception amounts within each sampling window are calculated (which can be determined based on ACK information). Then, the packet loss rate at the current time point of each sampling window is calculated based on the ratio of data transmission to data reception, for example, packet loss rate = (data transmission amount - data reception amount) / data transmission amount. Optionally, the calculated <timestamp, packet loss rate> data pairs can be stored in a TimeSeries object for easy retrieval of packet loss rates at different times.

[0102] For example, multiple packet loss rates for a first time length and multiple packet loss rates for a second time length are determined. A first quantile packet loss rate for the first time length and an average packet loss rate for the second time length are determined based on these packet loss rates. The packet loss rate variance for the second time length is then determined based on the average packet loss rate for the second time length. Optionally, the first quantile provided in this scheme can be a 10% to 40% quantile, such as a 20% quantile. In one embodiment, the multiple packet loss rates for the first time length can be determined based on the packet loss rates corresponding to one or more sampling windows within the first time length, and the multiple packet loss rates for the second time length can be determined based on the packet loss rates corresponding to one or more sampling windows within the second time length, wherein the first time length is greater than the second time length.

[0103] The first quantile packet loss rate over a first time length is used as the first baseline packet loss rate, and the average packet loss rate over a second time length is used as the second baseline packet loss rate. The first baseline packet loss rate can be used to quantify the random packet loss rate of the physical link, while the second baseline packet loss rate can be used to quantify the actual packet loss rate under multi-stream conditions on the current link.

[0104] The current packet loss rate during real-time call data transmission is calculated. This current packet loss rate can be derived from the data transmission and reception volume over a recently set time period (e.g., 500ms). Simultaneously, a first average packet loss rate over a third time period and a second average packet loss rate over a fourth time period are determined. In one embodiment, the first average packet loss rate can be determined based on multiple packet loss rates corresponding to one or more sampling windows within the third time period, and the second average packet loss rate can be determined based on multiple packet loss rates corresponding to one or more sampling windows within the fourth time period. The fourth time period is longer than the third time period.

[0105] Furthermore, based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the packet loss rate variance, the first average packet loss rate, and the second average packet loss rate determined above, it is determined whether packet loss-based network congestion has occurred.

[0106] In one embodiment, whether packet loss-based network congestion occurs can be determined based on the following criteria: Condition 1: The first average packet loss rate is greater than the sum of the second baseline packet loss rate, the packet loss rate variance, and a set first tolerance threshold; Condition 2: The current packet loss rate is greater than the sum of the second baseline packet loss rate and a set second tolerance threshold; Condition 3: The second average packet loss rate is greater than the sum of the second baseline packet loss rate and a set third tolerance threshold; Condition 4: The second average packet loss rate is greater than the sum of the first baseline packet loss rate and a set fourth tolerance threshold; Condition 5: The current packet loss rate is greater than the sum of the first baseline packet loss rate and a set fifth tolerance threshold. Optionally, the second tolerance threshold > the third tolerance threshold > the first tolerance threshold > the fourth tolerance threshold > the fifth tolerance threshold. For example, if condition 5 is satisfied, and any one of conditions 1-4 is also satisfied, packet loss-based network congestion is confirmed to have occurred; otherwise, non-packet loss-based network congestion is considered (e.g., if condition 5 is not satisfied, or if conditions 1-4 are not satisfied).

[0107] This solution accurately determines whether packet loss-based network congestion has occurred by using the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the packet loss rate variance, the first average packet loss rate, and the second average packet loss rate. It accurately identifies the timing for entering the bitrate limiting state and limits the encoding bitrate in a timely manner. While ensuring effective bandwidth utilization, it also controls the bitrate from excessively increasing, thereby ensuring that users can have a stable, clear, and smooth audio and video call experience even in complex network conditions.

[0108] In one possible embodiment, the real-time communication congestion control method provided by this solution determines whether packet-loss-based network congestion has occurred based on the current packet loss rate, a first baseline packet loss rate, a second baseline packet loss rate, packet loss rate variance, a first average packet loss rate, and a second average packet loss rate, including:

[0109] S2031: Within the rate-limited period, determine whether packet-based network congestion has occurred based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, and the second average packet loss rate.

[0110] S2032: Outside of the rate-limited period, determine whether packet-based network congestion has occurred based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the packet loss rate variance, the first average packet loss rate, and the second average packet loss rate.

[0111] For example, when determining whether network congestion based on packet loss has occurred, the data used for determining network congestion based on packet loss can be determined by whether the current time is within the rate-limiting period. Specifically, if the time distance between the current time and the time distance of the network congestion occurrence is within the rate-limiting period, the current time is determined to be within the rate-limiting period. Conversely, if no network congestion is detected, or if the time distance between the current time and the time distance of the network congestion occurrence is greater than the rate-limiting period, the current time is determined to be outside the rate-limiting period.

[0112] If the current time is outside the rate-limited period, then based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the packet loss rate variance, the first average packet loss rate, and the second average packet loss rate, it is determined whether packet loss-based network congestion has occurred. That is, if condition 5 is met, and any one of conditions 1-4 is met at the same time, packet loss-based network congestion is confirmed to have occurred.

[0113] Within the rate-limited period, network congestion based on packet loss is determined based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, and the second average packet loss rate, ignoring the packet loss rate variance and the first average packet loss rate. When determining whether to send network congestion based on packet loss based on judgment conditions, conditions 1 and 2 can be ignored. For example, if condition 5 is met, and either condition 3 or 4 is also met, network congestion based on packet loss is confirmed; otherwise, it is considered not to be network congestion based on packet loss (e.g., condition 5 is not met, or neither condition 3 nor 4 is met). Conditions 1-3 are short-term (third time length) judgment conditions. Conditions 1 and 2 are not judged under rate-limited conditions. The duration of judgment condition 3 is longer than that of judgment conditions 1 and 2. Although instantaneous packet loss congestion under rate-limited conditions is considered less related to the current flow, if the phenomenon persists, and judgment condition 3 persists for a longer period than judgment conditions 1 and 2 under rate-limited conditions, congestion judgment is still used for congestion detection, achieving a fallback detection of congestion.

[0114] This solution determines the data used for packet loss-based network congestion assessment based on whether the current time is within the bitrate limiting period, effectively reducing the computational load of packet loss-based network congestion assessment and improving network congestion control efficiency. It should be explained that when combining bitrate limiting with congestion control, packet loss congestion assessments based on short-term (third time length) packet loss rate changes under bitrate limiting conditions can be cancelled. Since real-time calls under bitrate limiting conditions do not change the bitrate, recent increases in packet loss are not highly correlated with the current flow and can be disregarded as a basis for congestion assessment, thereby improving the anti-competition capability of real-time calls.

[0115] In one embodiment, latency jitter congestion detection based on limited bitrate is similar to packet loss congestion detection. Latency jitter congestion detection can determine whether network congestion has occurred by dividing time windows of different lengths and analyzing network quality changes from long to short time periods. For example, it can calculate the standard score (ZScore) of latency for each time window and then compare it with the corresponding standard score threshold Ti to determine whether network congestion has occurred. It should be explained that the statistical standard score is used to measure the deviation of a sample point from the sample group. In this scheme, the sample point is the average latency within each time window, and the sample group is considered the baseline latency within the fifth time period. The standard deviation of the sample group itself can be measured by the standard deviation of latency jitter within the fifth time period. Therefore, when the standard score within a certain time window is too high, it is statistically considered an outlier, and latency-based network congestion can be considered to have occurred at this time. Here, latency is the round-trip time of call data from the congestion control device to the data receiver, and jitter is the time difference between the maximum and minimum latency within the time window.

[0116] In one possible embodiment, such as Figure 5 As shown in the schematic diagram of a latency network congestion detection process, the congestion control method for real-time communication provided in this solution, before determining the rate limiting period upon detecting network congestion, also includes:

[0117] S204: Determine the reference delay based on the second quantile delay at the fifth time length, and determine the jitter standard deviation at the fifth time length.

[0118] S205: Determine the standard score of latency based on the first average latency, the reference latency, and the jitter standard deviation corresponding to multiple time windows before the current time.

[0119] S206: Determine whether delay-based network congestion has occurred based on the delay standard score and the set standard score threshold.

[0120] For example, multiple delay and jitter information points within a fifth time length are determined, and a second quantile delay within the fifth time length is determined based on the delay information, and this second quantile delay is used as the baseline delay. The jitter standard deviation within the fifth time length is also determined based on the jitter information. Optionally, the second quantile provided in this solution can be a 5% to 30% quantile, such as a 10% quantile. In one embodiment, the multiple delay and jitter information points within the fifth time length can be determined based on delay and jitter information recorded within one or more sampling windows within the fifth time length. Optionally, the fifth time length can be set to be consistent with the first time length.

[0121] Furthermore, a first average delay is determined corresponding to multiple delay information records across multiple time windows prior to the current time. A delay standard score is then determined based on the first average delay, the baseline delay, and the jitter standard deviation. Optionally, the delay standard score can be determined based on the ratio of the difference between the first average delay and the baseline delay to the jitter standard deviation. Optionally, the delay standard score can be determined based on the following formula:

[0122]

[0123] Where Zscore is the standard score for latency, and UTT is... i For the first average delay, UTT base JitterStd is the reference delay. long The standard deviation of jitter.

[0124] Furthermore, for each time window, the determined latency standard score is compared with a set standard score threshold to determine whether latency-based network congestion has occurred. For example, if the latency standard score is greater than the set standard score threshold, latency-based network congestion is determined to have occurred; if the latency standard score is less than the set standard score threshold, latency-based network congestion is determined not to have occurred, and the latency standard score corresponding to the next time window is used to determine whether latency-based network congestion has occurred. In one embodiment, different time windows of different lengths can correspond to different standard score thresholds. The longer the time window, the smoother the overall latency jitter should be, allowing for a lower standard score threshold to more accurately determine whether latency-based network congestion has occurred.

[0125] This solution accurately determines whether latency-based network congestion occurs based on latency standard scores and set standard score thresholds, accurately identifies the timing for entering bitrate limiting state, and promptly limits the encoding bitrate. While ensuring effective bandwidth utilization, it also controls excessive bitrate spikes, thereby ensuring that users can have a stable, clear, and smooth audio and video call experience even in complex network conditions.

[0126] In one possible embodiment, the congestion control method for real-time communication provided by this solution, when determining whether delay-based network congestion has occurred based on a delay standard score and a set standard score threshold, may be:

[0127] S2061: In shallow cache state, lower the set standard score threshold.

[0128] S2062: Determine whether delay-based network congestion has occurred based on the delay standard score and the reduced standard score threshold.

[0129] The shallow buffer state provided by this solution can be understood as the state in which communication data within a set capacity (smaller capacity) is buffered within the network device responsible for forwarding communication data. For example, when a data packet containing call data is sent to a network device such as a router, due to factors such as network device performance or bandwidth, the data packet cannot be forwarded immediately but will be buffered in the network device. The shallow buffer state is defined as the amount of buffered data within the set capacity. The shallow buffer state can be determined by probing the amount of data buffered in the network device.

[0130] For example, when it is detected that the network device responsible for forwarding call data is in a shallow buffer state, a standard score threshold is first determined, and then the standard score threshold is reduced. For example, the standard score threshold is multiplied by a set shallow buffer coefficient (the shallow buffer coefficient is less than 1) to obtain the reduced standard score threshold.

[0131] Furthermore, the system determines whether latency-based network congestion has occurred based on the latency standard score and the reduced standard score threshold. For example, if the latency standard score is greater than the reduced standard score threshold, latency-based network congestion is determined to have occurred; if the latency standard score is less than the reduced standard score threshold, latency-based network congestion is determined not to have occurred, and the system continues to use the latency standard score corresponding to the next time window to determine whether latency-based network congestion has occurred. This scheme, by reducing the set standard score threshold in the shallow buffer state, more accurately determines whether latency-based network congestion has occurred, accurately confirms the timing of entering the bitrate limiting state, and limits the coding bitrate in a timely manner.

[0132] In one possible embodiment, the congestion control method for real-time communication provided by this solution, when determining whether delay-based network congestion has occurred based on a delay standard score and a set standard score threshold, may be:

[0133] S2063: If the latency standard score is greater than the set standard score threshold and the current time is within the bit rate limiting period, determine whether latency-based network congestion has occurred based on the first average latency, the baseline latency, and the set standard score threshold.

[0134] S2064: Determine that latency-based network congestion has occurred if the latency standard score is greater than the set standard score threshold and the current time is outside the bitrate limiting period.

[0135] For example, when the latency standard score is greater than a set standard score threshold, it is determined whether the current time is within the bitrate limiting period, i.e., whether the current state is still under bitrate limiting. If the latency standard score is greater than the set standard score threshold and the current time is outside the bitrate limiting period (i.e., the current state is not under bitrate limiting), then latency-based network congestion is determined to have occurred.

[0136] If the latency standard score is greater than a set standard score threshold, and the current time is within the bitrate limiting period, then it is determined whether latency-based network congestion has occurred based on the first average latency, the baseline latency, and the set standard score threshold. For example, it is determined whether the difference between the first average latency and the baseline latency is less than the standard score threshold. If the difference between the first average latency and the baseline latency is less than the standard score threshold, then latency-based network congestion is considered to have occurred; otherwise, it is determined that no latency-based network congestion has occurred, and the latency standard score corresponding to the next time window is used to determine whether latency-based network congestion has occurred.

[0137] In one embodiment, when determining whether latency-based network congestion has occurred based on a first average latency, a baseline latency, and a set standard score threshold, a set threshold coefficient can be added to adjust the standard score threshold. That is, the determination of whether latency-based network congestion has occurred is based on the first average latency, the baseline latency, the set threshold coefficient, and the set standard score threshold. For example, it is determined whether the difference between the first average latency and the baseline latency is less than the product of the standard score threshold and the set threshold coefficient. If the difference between the first average latency and the baseline latency is less than the product of the standard score threshold and the set threshold coefficient, then latency-based network congestion is considered to have occurred; otherwise, it is determined that latency-based network congestion has not occurred, and the latency standard score corresponding to the next time window is used to continue determining whether latency-based network congestion has occurred. The set threshold coefficient is greater than 1. In a rate-limited state, the bitrate will remain unchanged. If latency jitter is significant, mainly due to the influence of other streams, a higher standard score threshold can be used to improve competitiveness. When ignoring congestion assessments with relatively small jitter under rate-limited conditions, a higher standard score threshold for congestion assessment is needed to more accurately determine whether latency-based network congestion has occurred, accurately identify the timing of entering rate-limited conditions, and promptly limit the encoding rate.

[0138] The above describes a method that, upon detecting network congestion, enters a rate-limiting state based on a set rate-limiting period. The current rate-limiting bitrate is determined by historical rate-limiting bitrates and the maximum received bitrate at the data receiver during network congestion. Network congestion control is then performed based on this current rate-limiting bitrate. The probe bitrate is obtained by probing the bitrate when the duration of network congestion reaches a set probe waiting time, or by probing the bitrate after each rate-limiting period. Within the rate-limiting period, network congestion control is performed based on this current rate-limiting bitrate. This approach ensures the bitrate is close to the rate limit under the current network environment while effectively reducing the number of rate probes, minimizing bitrate fluctuations caused by frequent probes, and improving the user's real-time communication experience. Furthermore, by probing the bitrate when the duration of network congestion reaches the set probe waiting time, or when the time interval since the last rate probe reaches the rate-limiting period, the system attempts to acquire more network bandwidth for data transmission. This effectively reduces network bandwidth drops caused by prolonged periods without rate probes, further improving network congestion control quality and enhancing user experience. Furthermore, based on the packet loss rate and / or latency jitter during real-time call network data transmission, it determines whether network congestion has occurred, accurately identifies the timing of entering the bitrate limiting state, and promptly limits the encoding bitrate. While ensuring effective bandwidth utilization, it also controls excessive bitrate increases, thereby ensuring that users can have a stable, clear, and smooth audio and video call experience even in complex network conditions.

[0139] Figure 6 This is a schematic diagram of the structure of a congestion control device for real-time communication provided in an embodiment of this application. (Reference) Figure 6 The congestion control device for real-time communication includes a period determination module 61, a bit rate determination module 62, a first encoding module 63, and a second encoding module 64.

[0140] The system includes a period determination module 61, configured to determine a rate limiting period when network congestion is detected; a rate determination module 62, configured to determine the current rate limiting based on historical rate limiting and the maximum received rate at the data receiver during network congestion; a first encoding module 63, configured to perform encoding based on the current rate limiting within a set probe waiting time; and a second encoding module 64, configured to perform encoding based on the probe rate after the probe waiting time, wherein the probe rate is obtained when the duration of network congestion reaches the set probe waiting time, or after each rate limiting period.

[0141] The above describes a method that, upon detecting network congestion, enters a rate-limiting state based on a set rate-limiting period. The current rate-limiting bitrate is determined based on historical rate-limiting bitrates and the maximum received bitrate at the data receiver during network congestion. Network congestion control is then performed based on this current rate-limiting bitrate. The probe bitrate is obtained by probing the bitrate when the duration of network congestion reaches a set probe waiting time, or by probing the bitrate after each rate-limiting period. Within the rate-limiting period, network congestion control is performed based on the current rate-limiting bitrate. This approach ensures the bitrate is close to the rate limit under the current network environment while effectively reducing the number of rate probes, minimizing bitrate fluctuations caused by frequent probes, and improving the user's real-time communication experience.

[0142] In one possible embodiment, the period determination module 61 is configured to determine a rate limiting period based on a set limiting period, a historical limiting rate, and the maximum received rate of the data receiver when network congestion is detected.

[0143] In one possible embodiment, when determining the rate limiting period based on the set limiting period, the historical limiting rate, and the maximum received rate of the data receiver during network congestion, the period determination module 61 is configured as follows:

[0144] When network congestion occurs, if the difference between the maximum received bit rate of the data receiver and the historical limit bit rate is less than the first threshold, the set limit period is increased to obtain the bit rate limit period.

[0145] When network congestion occurs, if the difference between the maximum received bit rate of the data receiver and the historical limited bit rate is between the first threshold and the second threshold, the set limiting period is reduced to obtain the bit rate limiting period, where the second threshold is greater than the first threshold.

[0146] When network congestion occurs, if the difference between the maximum received bitrate of the data receiver and the historical limit bitrate is greater than the second threshold, the set limit period is adjusted to the set minimum period to obtain the bitrate limit period.

[0147] In one possible embodiment, the bit rate determination module 62 is configured as follows:

[0148] The first bit rate is determined based on the maximum received bit rate at the data receiver during network congestion and the set bit rate coefficient.

[0149] The current limited bitrate is obtained by performing a moving average of the first bitrate and the historical limited bitrates based on the set weight coefficients.

[0150] In one possible embodiment, the congestion control device further includes a rate upscaling module, which is configured to perform rate upscaling to obtain the probe rate when the duration of network congestion reaches a set probe waiting time, or when the time interval since the last rate upscaling reaches a rate limit period.

[0151] In one possible embodiment, the bitrate upprobing module is configured as follows when it obtains the probe bitrate through bitrate upprobing:

[0152] If the time interval between the last bitrate increase and the last bitrate increase reaches the set detection time interval, the detection bitrate is obtained by increasing the bitrate based on the current limit bitrate or the historical detection bitrate.

[0153] If the time interval since the last bitrate increase is less than the set probe interval, the probe bitrate is determined based on the current estimated bitrate and the current limit bitrate.

[0154] In one possible embodiment, when the rate upprobing module obtains the probed rate by upprobing based on the current limited bitrate or the historical probed bitrate, it is configured as follows:

[0155] The probe factor is determined based on the number of consecutive rate probes.

[0156] The probe rate is obtained by probing upwards based on the probe factor and the current limit bit rate or historical probe bit rate.

[0157] In one possible implementation, the detection factor is determined based on the following formula:

[0158] F probe =min((I probe / 2+1)*10,20)

[0159] Among them, I probe This represents the number of consecutive attempts to increase the bit rate.

[0160] The probe rate is determined based on the following formula:

[0161] R = min(R) max R2 probe )

[0162] R max =max(R) rm *1.5, R rm +300)

[0163] R2 probe =max(R1) probe +20, R1 probe *(1+F probe / 100)

[0164] R1 prone =ax(R) last *1.3, R last +20)

[0165] Among them, R rm R represents the maximum receive bit rate at the data receiver during network congestion. last This is the historical limit bitrate.

[0166] In one possible embodiment, the congestion control device for real-time communication further includes a packet loss congestion judgment module, which is configured as follows:

[0167] A first baseline packet loss rate is determined based on a first quantile packet loss rate over a first time length, and a packet loss rate variance and a second baseline packet loss rate are determined based on an average packet loss rate over a second time length, wherein the first time length is greater than the second time length.

[0168] Determine the current packet loss rate, the first average packet loss rate in the third time length, and the second average packet loss rate in the fourth time length, where the fourth time length is greater than the third time length.

[0169] Based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the first average packet loss rate, and the second average packet loss rate, determine whether packet loss-based network congestion has occurred.

[0170] In one possible embodiment, when the packet loss congestion determination module determines whether packet loss-based network congestion has occurred based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the first average packet loss rate, and the second average packet loss rate, it is configured as follows:

[0171] Within the rate-limited period, based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, and the second average packet loss rate, it is determined whether packet loss-based network congestion has occurred.

[0172] Outside of the rate-limited period, based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the packet loss rate variance, the first average packet loss rate, and the second average packet loss rate, it is determined whether packet loss-based network congestion has occurred.

[0173] In one possible embodiment, the congestion control device for real-time communication further includes a delay congestion judgment module, which is configured as follows:

[0174] The reference delay is determined based on the second quantile delay at the fifth time length, and the jitter standard deviation at the fifth time length is determined.

[0175] Determine the standard score of latency based on the first average latency, the baseline latency, and the jitter standard deviation corresponding to multiple time windows prior to the current time.

[0176] Determine whether latency-based network congestion has occurred based on the latency standard score and the set standard score threshold.

[0177] In one possible embodiment, when the delay congestion determination module determines whether delay-based network congestion has occurred based on a delay standard score and a set standard score threshold, it is configured as follows:

[0178] In shallow cache mode, lower the set standard score threshold;

[0179] Determine whether latency-based network congestion has occurred based on the latency standard score and the reduced standard score threshold.

[0180] In one possible embodiment, when the delay congestion determination module determines whether delay-based network congestion has occurred based on a delay standard score and a set standard score threshold, it is configured as follows:

[0181] If the latency standard score is greater than the set standard score threshold and the current time is within the bitrate limiting period, determine whether latency-based network congestion has occurred based on the first average latency, the baseline latency, and the set standard score threshold.

[0182] If the latency standard score is greater than the set standard score threshold and the current time is outside the bitrate limit period, latency-based network congestion is determined to have occurred.

[0183] It is worth noting that in the embodiments of the above-mentioned real-time communication congestion control device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the protection scope of the embodiments of the present invention.

[0184] This application also provides a real-time communication congestion control device, which can integrate the real-time communication congestion control apparatus provided in this application. Figure 7 This is a schematic diagram of the structure of a real-time communication congestion control device provided in an embodiment of this application. (Reference) Figure 7 The real-time communication congestion control device includes: an input device 73, an output device 74, a memory 72, and one or more processors 71; the memory 72 is used to store one or more programs; when one or more programs are executed by one or more processors 71, the one or more processors 71 implement the real-time communication congestion control method provided in the above embodiments. The real-time communication congestion control device, apparatus, and computer provided above can be used to execute the real-time communication congestion control method provided in any of the above embodiments, and have corresponding functions and beneficial effects.

[0185] This application also provides a non-volatile storage medium for storing computer-executable instructions. When executed by a computer processor, these computer-executable instructions are used to perform the congestion control method for real-time communication provided in the above embodiments. Of course, the computer-executable instructions provided in this application are not limited to the congestion control method for real-time communication provided above; they can also perform related operations in the congestion control method for real-time communication provided in any embodiment of this application. The congestion control device, apparatus, and storage medium for real-time communication provided in the above embodiments can execute the congestion control method for real-time communication provided in any embodiment of this application. Technical details not described in detail in the above embodiments can be found in the congestion control method for real-time communication provided in any embodiment of this application.

[0186] Based on the above embodiments, this application also provides a computer program product. The technical solution of this application, in essence or in other words, the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes several instructions to cause a computer device, mobile terminal, or processor therein to execute all or part of the steps of the real-time communication congestion control method provided in the various embodiments of this application.

Claims

1. A congestion control method for real-time communication, characterized in that, include: In the event of network congestion, the rate limiting period is determined based on the set limiting period, the historical rate limiting rate, and the maximum received rate of the data receiver when the network congestion occurs. The current limiting bit rate is determined based on the historical limiting bit rate and the maximum receiving bit rate of the data receiver when the network congestion occurs; Encoding processing is performed based on the current limited bitrate within a set detection waiting time. The set detection waiting time is the time to wait for the first bitrate increase after detecting network congestion. The bitrate limiting period is longer than the set detection waiting time. After the set probe waiting time, encoding processing is performed based on the probe bitrate. The probe bitrate is obtained by probing the bitrate when the duration of network congestion first reaches the set probe waiting time; or by probing the bitrate when the duration of network congestion again reaches the set probe waiting time, and the time interval between the last bitrate probing reaches the bitrate limit period.

2. The congestion control method for real-time communication according to claim 1, characterized in that, The step of determining the rate limiting period based on a set limiting period, historical rate limits, and the maximum received rate at the data receiver during network congestion includes: When network congestion occurs, if the difference between the maximum received bit rate of the data receiver and the historical limited bit rate is less than a first threshold, the set limiting period is increased to obtain the bit rate limiting period. When network congestion occurs, if the difference between the maximum received bit rate of the data receiver and the historical limited bit rate is between a first threshold and a second threshold, the set limiting period is reduced to obtain the bit rate limiting period, where the second threshold is greater than the first threshold. When network congestion occurs, if the difference between the maximum received bit rate of the data receiver and the historical limited bit rate is greater than the second threshold, the set limiting period is adjusted to the set minimum period to obtain the bit rate limiting period.

3. The congestion control method for real-time communication according to claim 1, characterized in that, Determining the current limiting bit rate based on the historical limiting bit rate and the maximum receiving bit rate of the data receiver when the network congestion occurs includes: The first code rate is determined based on the maximum received code rate of the data receiver when the network congestion occurs and the set code rate coefficient; The current limited bitrate is obtained by performing a moving average of the first bitrate and the historical limited bitrate based on the set weight coefficients.

4. The congestion control method for real-time communication according to claim 1, characterized in that, The bitrate increase includes: If the time interval between the last bitrate increase and the last bitrate increase reaches the set detection time interval, the detection bitrate is obtained by increasing the bitrate based on the current limit bitrate or the historical detection bitrate. If the time interval between the last bitrate increase and the last bitrate increase is less than the set detection time interval, the detection bitrate is determined based on the current estimated bitrate and the current limited bitrate, wherein the current estimated bitrate is obtained by adjusting the current limited bitrate according to a pre-configured bitrate control strategy.

5. The congestion control method for real-time communication according to claim 4, characterized in that, The step of obtaining the probe bitrate by probing upwards based on the current limited bitrate or historical probe bitrate includes: The probe factor is determined based on the number of consecutive rate probes. The probe rate is obtained by probing upwards based on the probe factor and the current limit bit rate or historical probe bit rate.

6. The congestion control method for real-time communication according to claim 5, characterized in that, The detection factor is determined based on the following formula: in, This represents the number of consecutive attempts to increase the bit rate. The probe rate is determined based on the following formula: R=min(R max ,R2 probe ) R max =max(R rm *1.5,R rm +300) R2 probe =max(R1 probe +20,R1 probe *(1+F probe / 100)) R1 probe =max(R last *1.3,R last +20) in, To detect the bit rate, This represents the maximum receive bit rate at the data receiver during network congestion. Based on maximum received code rate The first candidate bitrate, when first entering the probing state for bitrate probing... Given the current bitrate limit, when attempting to increase the bitrate during non-first entry into the probing state, For historical detection bit rate, The intermediate bitrate is determined based on the current limited bitrate or the historical probe bitrate. The second candidate code rate is determined based on the intermediate code rate; wherein, when the duration of network congestion first reaches the set probe waiting time, it is determined as the first entry into the probe state.

7. The congestion control method for real-time communication according to claim 1, characterized in that, Before determining the bitrate limiting period, the following is also included: A first baseline packet loss rate is determined based on a first quantile packet loss rate over a first time length, and a packet loss rate variance and a second baseline packet loss rate are determined based on an average packet loss rate over a second time length, wherein the first time length is greater than the second time length. Determine the current packet loss rate, the first average packet loss rate at a third time length, and the second average packet loss rate at a fourth time length, wherein the fourth time length is greater than the third time length; Based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the first average packet loss rate, and the second average packet loss rate, determine whether packet loss-based network congestion has occurred.

8. The congestion control method for real-time communication according to claim 7, characterized in that, The step of determining whether packet loss-based network congestion has occurred based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the first average packet loss rate, and the second average packet loss rate includes: If the time distance of network congestion is within the current bitrate limit period, determine whether network congestion based on packet loss has occurred based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, and the second average packet loss rate. If no network congestion is detected, or if the time distance from the current time to the occurrence of network congestion is greater than the current rate limit period, determine whether packet-based network congestion has occurred based on the current packet loss rate, the first baseline packet loss rate, the second baseline packet loss rate, the packet loss rate variance, the first average packet loss rate, and the second average packet loss rate.

9. The congestion control method for real-time communication according to claim 1, characterized in that, Before determining the bitrate limiting period, the following is also included: The reference delay is determined based on the second quantile delay at the fifth time length, and the jitter standard deviation at the fifth time length is determined. Based on the first average latency, the baseline latency, and the jitter standard deviation corresponding to multiple time windows prior to the current time, a latency standard score is determined. Whether delay-based network congestion has occurred is determined based on the aforementioned delay standard score and the set standard score threshold.

10. The congestion control method for real-time communication according to claim 9, characterized in that, The step of determining whether delay-based network congestion has occurred based on the delay standard score and a set standard score threshold includes: In shallow cache mode, lower the set standard score threshold; Whether delay-based network congestion has occurred is determined based on the latency standard score and the reduced standard score threshold.

11. The congestion control method for real-time communication according to claim 9, characterized in that, The step of determining whether delay-based network congestion has occurred based on the delay standard score and a set standard score threshold includes: If the latency standard score is greater than the set standard score threshold, and the current time distance from the occurrence of network congestion is within the current bitrate limiting period, it is determined whether latency-based network congestion has occurred based on the first average latency, the reference latency, and the set standard score threshold. If the latency standard score is greater than the set standard score threshold and no network congestion is detected, or if the current time distance from the occurrence of network congestion is greater than the current bitrate limit period, then latency-based network congestion is determined to have occurred.

12. A congestion control device for real-time communication, characterized in that, It includes a period determination module, a bitrate determination module, a first encoding module, and a second encoding module, wherein: The period determination module is configured to determine the bit rate limiting period based on a set limiting period, historical limiting bit rates, and the maximum receiving bit rate of the data receiver when network congestion is detected. The bitrate determination module is configured to determine the current bitrate based on the historical bitrate limit and the maximum received bitrate of the data receiver when the network congestion occurs. The first encoding module is configured to perform encoding processing based on the current limited bit rate within a set detection waiting time. The set detection waiting time is the time to wait for the first bit rate increase after detecting network congestion. The bit rate limiting period is longer than the set detection waiting time. The second encoding module is configured to perform encoding processing based on the probe bitrate after the set probe waiting time. The probe bitrate is obtained by probing the bitrate when the duration of the network congestion first reaches the set probe waiting time; or by probing the bitrate when the duration of the network congestion again reaches the set probe waiting time, and the time interval between the last bitrate probing reaches the bitrate limit period.

13. A congestion control device for real-time communication, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the congestion control method for real-time communication as described in any one of claims 1-11.

14. A non-volatile storage medium for storing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the congestion control method for real-time communication as described in any one of claims 1-11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the congestion control method for real-time communication as described in any one of claims 1-11.

Images