A congestion control method, device and equipment

Abstract

Embodiments of the present application disclose a congestion control method, apparatus, and device, including: determining the expected weights of N video data streams, where the source addresses and destination addresses of the N video data streams are the same, and N is an integer greater than 1; determining a combined transmission metric based on the transmission metrics of the N video data streams, where the transmission metrics include one or more of packet loss rate, latency, and transmission rate; determining a combined bitrate based on the combined transmission metric; and determining the target bitrate of each of the N video data streams based on the combined bitrate and the expected weights. Embodiments of the present application can improve network efficiency.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of multimedia technologies, and in particular, to a congestion control method, apparatus, and device. Background Art

[0002] With the rapid development of information technology, the amount of data transmitted by users over the network is increasing. In the case of a larger amount of transmitted data in the network, the possibility of video transmission congestion is increasing. In the case of video transmission congestion, the transmission delay, packet loss rate, etc. of the network will increase significantly.

[0003] Among the large amount of data transmitted in the network, the transmission directions of many data are the same. Exemplarily, in an autonomous driving vehicle system, multiple cameras, sensors, and radar monitoring systems need to be installed on the autonomous driving vehicle, and the data collected by these devices needs to be transmitted to the network side in real time, and these transmitted data all have the same source address and destination address.

[0004] However, in the case where the source addresses and destination addresses of multiple data streams are the same, when these multiple data streams are transmitted simultaneously, the multiple data streams compete for network resources, and the competition of a large amount of data will greatly increase the possibility of network congestion, thereby possibly resulting in low network transmission efficiency. Summary of the Invention

[0005] Embodiments of the present application disclose a congestion control method, apparatus, and device for improving network efficiency.

[0006] In a first aspect, a congestion control method is disclosed, including: determining an expected weight of N video data streams, where the source addresses and destination addresses of the N video data streams are the same, and N is an integer greater than 1; determining a joint transmission metric based on the transmission metrics of the N video data streams, where the transmission metric includes one or more of a packet loss rate, a delay, and a transmission rate; determining a joint bitrate based on the joint transmission metric; and determining a target bitrate of each of the N video data streams based on the joint bitrate and the expected weight.

[0007] As a possible implementation, the target code rate includes a target encoding code rate and a target transmission rate. Determining the target code rate of each of the N video data streams based on the combined code rate and the expected weight includes: determining the proposed code rate of each of the N video data streams based on the combined code rate and the expected weight; determining the N target encoding code rates based on the proposed code rates and the expected encoding code rates of the N video data streams, where the N video data streams correspond one-to-one with the N target encoding code rates; determining the target transmission rate based on the proposed code rates of the N video data streams, where the N video data streams correspond one-to-one with the N target transmission rates; the method further includes: adjusting the corresponding encoding code rate based on the target encoding code rate of the N video data streams; adjusting the corresponding transmission rate based on the target transmission rate of the N video data streams.

[0008] As a possible implementation, determining the expected weight of the N video data streams includes: determining the expected encoding code rates of the N video data streams, where the N expected encoding code rates correspond one-to-one with the N video data streams; determining the proportion of the expected encoding code rate of the i-th video data stream in the sum of all expected encoding code rates of the N video data streams as the expected weight of the i-th video data stream.

[0009] As a possible implementation, when the transmission metric includes a packet loss rate, determining the combined transmission metric based on the transmission metrics of the N video data streams includes: determining the combined packet loss rate by weighted averaging the N packet loss rates and the N calculation weights of the N video data streams, where the N calculation weights correspond one-to-one with the N video data streams; when the transmission metric includes a latency, the method for determining the combined transmission metric based on the transmission metrics of the N video data streams further includes: determining the combined latency by averaging the latencies of the N video data streams; when the transmission metric includes a transmission rate, the method for determining the combined transmission metric based on the transmission metrics of the N video data streams further includes: determining the combined transmission rate by summing up the transmission rates of the N video data streams.

[0010] As a possible implementation, before determining the combined packet loss rate by weighted averaging the N packet loss rates and the N calculation weights of the N video data streams, the method further includes: determining the expected weight of the i-th video data stream as the calculation weight of the i-th video data stream; or, determining the proportion of the actual encoding code rate of the i-th video data stream in the sum of all actual encoding code rates of the N video data streams as the calculation weight of the i-th video data stream, where the N actual encoding code rates correspond one-to-one with the N video data streams; or, determining the proportion of the transmission rate of the i-th video data stream in the sum of all transmission rates of the N video data streams as the calculation weight of the i-th video data stream, where the N transmission rates correspond one-to-one with the N video data streams.

[0011] As a possible implementation manner, determining the joint code rate based on the joint transmission metric includes: inputting the joint transmission metric into a first congestion control algorithm to obtain the joint code rate.

[0012] A second aspect discloses a congestion control device, including: a first determination unit configured to determine an expected weight of N video data streams, where source addresses and destination addresses of the N video data streams are the same, and N is an integer greater than 1; a second determination unit configured to determine a joint transmission metric based on transmission metrics of the N video data streams, where the transmission metrics include one or more of a packet loss rate, a delay, and a transmission rate; a third determination unit configured to determine a joint code rate based on the joint transmission metric; and a fourth determination unit configured to determine a target code rate of each of the N video data streams based on the joint code rate and the expected weight.

[0013] As a possible implementation manner, the target code rate includes a target encoding code rate and a target transmission rate. The fourth determination unit is specifically configured to: determine a recommended code rate of each of the N video data streams based on the joint code rate and the expected weight; determine the N target encoding code rates based on the recommended code rates of the N video data streams and the expected encoding code rates, where the N video data streams correspond to the N target encoding code rates one by one; determine the target transmission rate based on the recommended code rates of the N video data streams, where the N video data streams correspond to the N target transmission rates one by one; the device further includes an adjustment unit configured to adjust a corresponding encoding code rate based on the target encoding code rate of the N video data streams; and further configured to adjust a corresponding transmission rate based on the target transmission rate of the N video data streams.

[0014] As a possible implementation manner, the first determination unit is specifically configured to: determine expected encoding code rates of N video data streams, where the N expected encoding code rates correspond to the N video data streams one by one; and determine the proportion of the expected encoding code rate of the i-th video data stream in the sum of all expected encoding code rates of the N video data streams as the expected weight of the i-th video data stream.

[0015] As a possible implementation manner, when the transmission metric includes a packet loss rate, the second determination unit is specifically configured to: determine a joint packet loss rate by weighted averaging the N packet loss rates and N calculation weights of the N video data streams, where the N calculation weights correspond to the N video data streams one by one; when the transmission metric includes a delay, the second determination unit is further specifically configured to: determine an average of the delays of the N video data streams as the joint delay; when the transmission metric includes a transmission rate, the second determination unit is further specifically configured to: determine a sum of the transmission rates of the N video data streams as the joint transmission rate.

[0016] As a possible implementation manner, before the second determining unit determines the weighted average of the N packet loss rates and the N calculation weights of the N video data streams as the joint packet loss rate, it is further configured to: determine the expected weight of the i-th video data stream as the calculation weight of the i-th video data stream; or, determine the ratio of the actual coding bitrate of the i-th video data stream to the sum of the actual coding bitrates of all N video data streams as the calculation weight of the i-th video data stream, where the N actual coding bitrates correspond one-to-one to the N video data streams; or, determine the ratio of the sending rate of the i-th video data stream to the sum of the sending rates of all N video data streams as the calculation weight of the i-th video data stream, where the N sending rates correspond one-to-one to the N video data streams.

[0017] As a possible implementation manner, the third determining unit is specifically configured to input the joint sending metric into a first congestion control algorithm to obtain a joint bitrate.

[0018] In a third aspect, a congestion control device is disclosed. The congestion control device includes: a processor and a memory; the processor is connected to the memory. Among them, the memory is used to store a computer program. When the computer program is executed by the processor, the computer device executes the method provided in the embodiments of the present application.

[0019] In a fourth aspect, a congestion control device is disclosed. The congestion control device may include: a processor, a memory, an input interface, and an output interface. The input interface is used to receive information from other devices outside the device, and the output interface is used to output information to other devices outside the device. When the processor executes the computer program stored in the memory, the processor executes the congestion control method disclosed in the first aspect or any implementation manner of the first aspect.

[0020] In a fifth aspect, a computer-readable storage medium is disclosed. The computer-readable storage medium stores a computer program or computer instructions. When the computer program or computer instructions are run, the congestion control method disclosed in the first aspect or any implementation manner of the first aspect is implemented.

[0021] In a sixth aspect, a computer program product is disclosed. The computer program product includes computer program code. When the computer program code is run, the above method is executed.

[0022] In the embodiments of the present application, the recommended bit rate of each video data stream can be determined based on the weights and combined bit rates of different video data streams, and data packets can be sent based on these recommended bit rates. Therefore, through the congestion control of multiple data in an overall manner, the congestion probability caused by competition of data with the same source and destination can be reduced, and the network efficiency can be improved. Secondly, since the weights of different video data streams are different, it is possible to effectively distinguish which data stream requires more transmission, so that it is possible to preferentially and effectively transmit certain data streams, and the probability of successful transmission of important video data streams can be increased. Furthermore, in the process of calculating the recommended bit rate of each video data stream, the current transmission metrics of each data stream are considered, and the network conditions of each data stream can be taken into account, so as to avoid the imbalance of single video data probability statistics, and further ensure the comprehensiveness and accuracy of the recommended bit rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 FIG. is a schematic diagram of the video data flow direction of congestion control disclosed in the embodiments of the present application;

[0024] Figure 2 FIG. is a schematic diagram of an autonomous driving data transmission scenario disclosed in the embodiments of the present application;

[0025] Figure 3 FIG. is a schematic diagram of the method flow of congestion control disclosed in the embodiments of the present application;

[0026] Figure 4 FIG. is a schematic diagram of another video data flow direction of congestion control disclosed in the embodiments of the present application;

[0027] Figure 5 FIG. is a schematic diagram of another method flow of congestion control disclosed in the embodiments of the present application;

[0028] Figure 6 FIG. is a schematic diagram of yet another video data flow direction of congestion control disclosed in the embodiments of the present application;

[0029] Figure 7 FIG. is a schematic diagram of the structure of a congestion control device disclosed in the embodiments of the present application;

[0030] Figure 8 FIG. is a schematic diagram of the structure of a congestion control device disclosed in the embodiments of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] The embodiments of the present application disclose a congestion control method, device and equipment for improving network efficiency. The following is a detailed description.

[0032] To facilitate the understanding of a congestion control method, device and equipment disclosed in the embodiments of the present application, the related technologies involved in the embodiments of the present application will be introduced first:

[0033] 1. Congestion Control

[0034] The congestion phenomenon during the process of network data transmission refers to the situation where, when there is too much data arriving at the communication network, this part of the network is unable to process it in time, resulting in a decline in the performance of this part and even the entire network. This phenomenon is like traffic congestion in a road network. When the number of vehicles in the road network increases significantly, the vehicle flows in various directions interfere with each other, causing the time for each vehicle to reach its destination to increase relatively, and even congestion occurs and the vehicle cannot move forward.

[0035] To prevent the sending device from sending too fast for the network to handle, congestion control technology can control the sending rate based on network conditions (such as the packet loss rate, latency, etc.) so that the sending rate matches the actual situation of the network to obtain a larger effective data transmission rate. In real-time video transmission applications, congestion control adjusts the sending rate and the coding bitrate.

[0036] 2. Google Congestion Control (GCC)

[0037] The congestion control algorithm proposed by Google, namely the GCC algorithm, is a dynamic control sending rate model based on the packet loss rate and latency. That is, the sending end can control the sending rate based on two methods: one is congestion control based on the packet loss rate; the other is congestion control based on latency.

[0038] In one case, the sending device can perform bitrate control based on the packet loss rate. The sending device can evaluate the congestion status through the packet loss rate and adjust the sending rate accordingly. For example, when the packet loss rate is greater than the first packet loss rate threshold, the sending end can reduce the sending rate; when the packet loss rate is less than the second packet loss rate threshold, the sending end can increase the sending rate, and in other cases, the sending rate can remain unchanged.

[0039] In another case, the sending device can perform bitrate control based on the latency. The sending end can obtain the network latency and detect the degree of overload based on the latency, and then adjust the sending rate based on the degree of overload. For example, in the case of overload, the bitrate coefficient is adjusted to a coefficient greater than 1; in the case of low load, the bitrate coefficient is adjusted to a coefficient less than 1; otherwise, the bitrate coefficient remains 1 unchanged.

[0040] Among them, the data bitrate refers to the number of data bits transmitted per unit time during data transmission, with units such as bps, kbps, and Mbps. The larger the bitrate, the higher the accuracy and the closer the file is to the original file.

[0041] 3. Bottleneck Bandwidth and Round-Trip Propagation Time (BBR)

[0042] In BBR, congestion control can be achieved through the bottleneck bandwidth (BtIBw) and the round-trip propagation time (RRT). It can make full use of the bandwidth on a network link with a certain packet loss rate and ensure a low latency.

[0043] Among them, the bottleneck bandwidth BtIBw can be understood as the minimum bandwidth in the network link. The maximum sending rate sample of the sliding window can be estimated based on the estimated bottleneck bandwidth. RTprop can be understood as the round-trip time of data packets without queuing in the network link, and the round-trip propagation time can refer to the total length of RTprop and the fixed queuing time. The bandwidth-delay product (BDP) after the sliding window is the product of BtIBw and RTprop.

[0044] To maintain a high throughput and low-latency data transmission situation, the BBR congestion control system can make the arrival rate of data packets equal to the bottleneck bandwidth of the data stream, and the amount of data being transmitted equal to the BDP. Specifically, in the startup state, the sending rate is rapidly increased; in the state of entering the drain, the pipeline queue is drained in a timely manner; in the state of bottleneck bandwidth detection, the amount of data transmitted can be briefly increased to detect a higher bottleneck bandwidth; in the state of latency detection, the amount of data in transmission can be briefly reduced to detect a lower latency.

[0045] 4. Cubic Congestion Control Algorithm

[0046] The window growth function of cubic is a cubic function, which can be divided into a stable growth stage and a maximum bandwidth detection stage. Among them, at the beginning of startup, the congestion window grows rapidly. When the window is close to Wmax, the growth rate gradually flattens to avoid packet loss caused by a sudden increase in the number of data flows; when near Wmax, the congestion window no longer increases and starts to detect the maximum throughput of the network to maintain stability; after being far from Wmax, the rate of window growth is increased to ensure the utilization rate of the bandwidth.

[0047] Among them, the cubic function is C and β are constants, and Wmax is the maximum value of the congestion window.

[0048] Specifically, when a congestion event occurs, Wmax is set to the window value at the time of congestion, and then the window is multiplicatively decreased with a multiplicative decrease factor of β. When exiting the fast recovery phase and entering the congestion avoidance phase, the window growth of cubic then starts to grow according to a "concave" growth curve. This process continues until the window grows back to Wmax again. Immediately afterwards, the function enters the "convex" growth phase. This way of growth can keep the window maintained near Wmax, thereby achieving high utilization of network bandwidth and the stability of the protocol itself.

[0049] It should be noted that the above several congestion control methods are only examples and are not limited. For example, Reno, Vegas, FastTCP (fast transmission control protocol), selective acknowledgment (SACK) congestion control algorithms, and so on.

[0050] The following describes a congestion control method involved in the embodiments of the present application.

[0051] Please refer to Figure 1 , Figure 1 which is a schematic diagram of the data flow of a congestion control disclosed in the embodiments of the present application. As Figure 1 shown, the sending end device may include an encoder module, a congestion window module, and a congestion control module. The congestion control module may be respectively connected to the encoder module and the congestion window module. When the encoder module receives a data stream, the encoder module may encode the data stream at a certain coding rate to obtain an encoded stream, and then the encoder module may send the encoded stream to the congestion window module. When the congestion window module receives the encoded stream, it sends data packets to the network at a certain window interval and window size. Among them, the congestion control module may adjust the coding rate of the encoder and / or the size and interval (transmission rate) of the congestion window through a congestion control algorithm.

[0052] Among them, the congestion control algorithm may be one of the above-mentioned congestion control algorithms such as GCC, BBR, and cubic, and the details are not elaborated here.

[0053] When the source addresses and destination addresses of multiple data streams are the same, each data stream needs to be transmitted separately. Current congestion control methods are all for each data stream to perform congestion control, which may lead to a large amount of data pouring into the same network transmission, increasing the possibility of network congestion. Exemplarily, in a remote control application, the controlling end needs to simultaneously observe the pictures from multiple perspectives of the controlled device. Therefore, the controlled device needs to simultaneously access multiple original data stream cameras through a gateway, encode and send the camera video streams, and these video streams will be simultaneously transmitted to the controlling end. When each data stream uses an independent congestion control mechanism, these multiple data streams are transmitted through a competition mechanism, increasing the possibility of network congestion. In addition, separate congestion control for each path may exacerbate network congestion, resulting in low network transmission efficiency.

[0054] Exemplarily, Figure 2 FIG. is a schematic diagram of an autonomous driving data transmission scenario disclosed in an embodiment of the present application. As Figure 2 shown, for example, in an in-vehicle system for autonomous driving, an autonomous driving vehicle (the sending end) may include multiple information collection devices. For example, a laser rangefinder is used to measure the distance between the autonomous driving vehicle and other surrounding objects. The in-vehicle radar system can detect the surrounding environment, sensors can collect vehicle-related data (temperature, humidity, tire pressure, etc.), cameras can collect video data outside and inside the vehicle, and so on. All kinds of data streams collected by the above-mentioned devices need to be sent to the server, and the server processes these multiple data streams. That is, the autonomous driving vehicle can transmit the collected data streams separately through the network. During the transmission of these multiple data streams, congestion control needs to be performed for different data streams. However, the competition of these multiple data streams for the network greatly increases the possibility of network congestion, resulting in low network efficiency. It should be noted that multiple data with the same source address and destination address can also be other scenarios, and the above is only an exemplary illustration without limitation.

[0055] To address the above problems, in an embodiment of the present application, when the source address and destination address of the video data stream are the same, centralized congestion control can be performed, that is, a joint congestion control module is connected to all other multiple encoder modules and multiple congestion window modules. The joint congestion control module determines the expected weight of each video data stream for different paths of video data streams, and can allocate the target bit rate of each data stream according to these expected weights, so as to adjust the sending rate and encoding bit rate of each video data stream based on the target bit rate of each video data stream. In this way, the transmission of multiple video data streams can be coordinated, reducing the probability of network congestion to improve network transmission efficiency.

[0056] Please refer to Figure 3, such as Figure 3 shown is a schematic flowchart of a congestion control method disclosed in an embodiment of the present application. Among them, this method can be applied to a sending device. A congestion control method may include the following steps:

[0057] Please refer to Figure 4 , Figure 4 is a schematic diagram of the video data flow of another congestion control disclosed in an embodiment of the present application. As Figure 4 shown, the sending device includes N encoder modules for N video data streams, N congestion window modules, and a joint congestion control module. This joint congestion control module is connected to the above-mentioned N encoder modules and N congestion window modules. The joint congestion control module can respectively adjust the encoding bit rate of the N encoder modules and the window size and interval (transmission rate) of the N congestion window modules. Among them, N is an integer greater than 1.

[0058] Exemplarily, the sending device can encode and send the first video data stream based on the encoder 1 module and the congestion window 1 module, and the joint congestion control module can make adjustments during the encoding and sending process. When the encoder 1 module receives the video data stream 1, it can encode the video data stream 1 to obtain the encoded stream 1. Then the encoder 1 can send the encoded stream to the congestion window 1 module. After the congestion window 1 module receives the encoded stream 1, it can send the encoded stream 1. The joint congestion control module can be connected to the encoder 1 module and the congestion window 1 module. The joint congestion control module can adjust the encoding bit rate of the encoder 1 module for the video data stream 1 and adjust the transmission rate of the congestion window 1 module for the encoded stream 1. It should be noted that the description of the second video data stream to the Nth video data stream can refer to the description of the first video data stream above and will not be elaborated.

[0059] In an embodiment of the present application, the sending device can be a camera device for an autonomous driving vehicle, or a multi-camera communication device for a drone, or a multi-channel camera communication device for a video surveillance system, etc. The above are only examples and are not limited.

[0060] The sending device can receive feedback information (such as transmission metrics) for the above N video data streams from the receiving end through the joint congestion control module. The sending device can execute the method flowchart as Figure 3 shown below for specific description:

[0061] S301. The sending device obtains the transmission metrics of the N video data streams.

[0062] The sending metrics include one or more of the packet loss rate (lost), round trip time (RTT), and sending rate (rate). Among them, the packet loss rate in the sending metrics may include from lost1...lost N A total of N packet loss rates; the round trip time may include from RTT1...RTT N A total of N round trip times; the sending rate may include from rate1...rate N A total of N sending rates. In addition, the N video data streams may be video data, and the source address and destination address of the N video data streams are the same, that is, the N video data flow directions are the same. As Figure 4 shown, N is an integer greater than 1.

[0063] The following describes the process by which the sending device determines the packet loss rate (lost), round trip time (RTT), and sending rate (rate) of N video streams:

[0064] The sending device can determine the packet loss rate based on the acknowledgement (ACK) message or the notacknowledgement (NACK) message. In one possible case, the sending device can determine the packet loss rate based on the ACK message. After the sending end sends video data packets to the receiving end, the receiving end can receive the video data packets from the sending end and feedback an ACK message to the sending end. The sending device can determine the current packet loss rate based on the number of ACK messages. For example, if the sending device sends 100 video data packets and receives 99 ACK messages, it can determine that the packet loss rate of this video is 1%. In another possible case, the sending device can determine the packet loss rate based on the NACK message. After the sending end sends video data packets to the receiving end, the receiving end can receive the video data packets from the sending end. In the case where the receiving end does not receive the video data packets, it feedbacks a NACK message to the sending end. The sending device can determine the current packet loss rate based on the size of the NACK message. For example, if the sending device sends 100 video data packets and receives 2 NACK messages, it can determine that the packet loss rate of this video is 2%.

[0065] The sending device can determine the time delay. In one case, the sending device can detect the round trip time (RTT) by sending an RTT ping signal. Herein, RTT refers to the total time elapsed from when the sending end starts sending data until the sending end receives the acknowledgment information from the receiving end (the receiving end sends the acknowledgment information immediately after receiving the data). In another possible case, the sending device can add a sending timestamp to each packet sent, and after receiving the feedback information, it can determine a receiving timestamp based on each feedback information. That is, the round trip time RTT can be determined as the time obtained by subtracting the sending timestamp from the receiving timestamp.

[0066] The sending device can determine the sending rate. In one case, the sending device can determine the sending rate based on the size of the sending window (i.e., the congestion window) at the sending end and the sending interval. In another case, the receiving device can count the received code rate and send the counted received code rate to the sending end. After receiving the code rate, the sending end can determine the received code rate as the sending rate.

[0067] Herein, the sending metrics obtained by the sending device can be the feedback data received from the receiving end. For example, Figure 2 in the shown autonomous driving system, the sending rate and the like feedback by the server.

[0068] It should be noted that the above methods for the sending device to determine the packet loss rate, time delay, and sending rate are merely examples, and other methods can also be used without limitation.

[0069] In the embodiments of the present application, when the source address and the destination address of the video data stream are the same, centralized congestion control can be performed, that is, a congestion control module is connected to all other encoder modules and congestion window modules. The congestion control module can adjust the sending rate and encoding code rate of different video data streams according to a certain proportion, so as to overall coordinate the transmission of multiple video data streams, reduce the probability of network congestion, and improve the network transmission efficiency.

[0070] S302. The sending device determines the expected weights of N video data streams.

[0071] The sending device can determine the expected weight w of each video based on the expected encoding code rate in the N video data streams i .

[0072] The following describes the implementation manner of determining the expected weight w of N video streams i :

[0073] In a possible implementation, the sending device may obtain the desired weights based on the clarity requirements. The clarity requirements may be quantization parameter (QP) requirements or bitrate requirements. The sending device may determine the desired weights w of the N video streams based on the desired encoding bitrate for each path. i The sending device may determine the proportion of the desired encoding bitrate of the i-th video data stream in the sum of all desired encoding bitrates of the N paths as the desired weight of the i-th path. The desired weights w of the N video streams i can be expressed as:

[0074]

[0075] where bitrate i is the desired encoding bitrate of the i-th path. The sending device may determine the desired encoding bitrate for each path based on the QP requirements or the bitrate requirements.

[0076] The following describes two ways to determine the desired encoding bitrate for each path:

[0077] In one possible way, the sending device may determine the desired encoding bitrate for each path based on the bitrate requirements. The higher the bitrate, the less the video data is compressed, the smaller the loss, and the closer the data is to the original data; conversely, the lower the bitrate, the less the video data is compressed, the greater the loss, and the more the obtained data deviates from the original data. Since the clarity requirements of the video data for different paths are different, the bitrate requirements are also different, and the sending device may store the desired encoding bitrate for each path in advance. Exemplarily, when N is 4, the desired encoding bitrate of the first path is 2 Mbps, the desired encoding bitrate of the second path is 3 Mbps, the desired encoding bitrate of the third path is 4 Mbps, and the desired encoding bitrate of the fourth path is 1 Mbps, then it can be obtained that w1 is 0.2; w2 is 0.3; w3 is 0.4; w4 is 0.1.

[0078] In another possible way, the sending device may also determine the desired encoding bitrates of the N video streams based on the quantization parameter requirements. The quantization parameter may represent the compression degree of image encoding. A larger QP value means a higher quantization degree, a higher compression degree, and a worse video quality; conversely, a smaller QP value means a lower quantization degree, a lower compression degree, and a better video quality. Exemplarily, the sending device may store the mapping relationship between the quantization parameter requirements and the desired encoding bitrates. When the quantization parameter requirements for each path are known, the sending device may determine the desired encoding bitrate for each path based on the above mapping relationship.

[0079] As described above, since the coding bit rate can reflect the degree to which data can be restored. For example, the higher the coding bit rate of a video stream, the better the clarity. By the magnitude of the coding bit rate, it is possible to distinguish that the requirements for different video data streams are different, so that more network resources can be allocated to the video data stream with higher requirements, in order to allocate more network resources to the video data stream with even higher requirements, thereby optimizing the allocation of network transmission resources.

[0080] In the above embodiments, and w i > 0.

[0081] It should be noted that the above-described embodiment of determining the expected weight w of N video data streams i is only for illustrative purposes and is not limited.

[0082] It should be noted that the execution order of steps S301 and S302 is not limited.

[0083] S303. The sending device determines a combined sending metric based on the sending metrics.

[0084] The sending device may determine a combined sending metric based on the above N sending metrics. The combined sending metric may include one or more of a combined packet loss rate, a combined delay, and a combined sending rate. That is, the sending device may determine a combined packet loss rate lost corp based on the N packet loss rates; determine a combined delay RTT corp based on the N delays; determine a combined sending rate rate corp . It should be noted that when the sending metric includes a packet loss rate, the combined packet loss rate will be determined; when the sending metric includes a delay, the combined delay will be determined; when the sending metric includes a sending rate, the combined sending rate will be determined. That is, the combined sending metric should correspond to the sending metric.

[0085] The following separately describes the embodiments in which the sending device determines the combined packet loss rate, the combined delay, and the combined sending rate:

[0086] 1. Determine the combined packet loss rate.

[0087] The sending device may first determine the calculation weight of each video data stream, and then may determine the combined packet loss rate based on the calculation weight of each video stream and the packet loss rate in the sending metric.

[0088] First, the sending device may first determine the calculation weight wc i of the N video streams based on the actual coding bit rate or sending rate of the N video streams. The following separately describes:

[0089] In a possible implementation, the sending-end device may determine the calculation weight wc of the N video streams based on the actual encoding bitrates of the N video streams i .

[0090] The sending-end device may first determine the actual encoding bitrates of the video data streams of each path through N encoders, and then may determine the proportion of the actual encoding bitrate of the i-th video data stream in the sum of all the actual encoding bitrates of the N paths as the calculation weight of the i-th path. At this time, the calculation weight of the i-th path can be expressed as:

[0091]

[0092] where bitrateactual i is the actual encoding bitrate of the i-th path.

[0093] As can be seen from the above, since the actual encoding bitrate can reflect the speed of data encoding. Through the magnitude of the actual encoding bitrate, it can be distinguished that the actual encoding bitrate requirements of different video data streams are different, so that more network resources can be allocated to the video data stream with a higher encoding bitrate requirement, thereby optimizing the allocation of network transmission resources.

[0094] In another possible implementation, the sending-end device may determine the calculation weight wc of the N video streams based on the sending rates of the N video streams i .

[0095] The sending-end device may first determine the sending rates of the video data streams of each path, and then may determine the proportion of the sending rate of the i-th video data stream in the sum of all the sending rates of the N paths as the calculation weight of the i-th path. At this time, the calculation weight of the i-th path can be expressed as:

[0096]

[0097] where rate i is the sending rate of the i-th path.

[0098] At this time, the sending-end device needs to first obtain the sending rates of the video data streams of each path. The obtaining method can refer to the description of S301 above and will not be elaborated.

[0099] In yet another possible implementation, the sending-end device may determine the calculation weight wc of the N video streams as the expected weight w of the N video streams i i .

[0100] The sending-end device may determine the expected weight of the i-th video data stream as the calculation weight of the i-th path. The calculation weight of the i-th video data stream can be expressed as:

[0101] where w​i is the expected weight of the i-th video data stream.

[0102] As can be seen from the above, since the sending rate can reflect the speed of data sending. By the magnitude of the sending rate, it is possible to distinguish that the sending rate requirements of different video data streams are different, so that more network resources can be allocated to the video data stream with higher sending rate requirements, thus optimizing the allocation of network transmission resources.

[0103] Secondly, the sending device can calculate the weight wc based on the packet loss rates of the N video data streams i to determine the combined packet loss rate.

[0104] The sending device can weight the packet loss rates of the N video data streams to determine the combined packet loss rate. That is, the combined packet loss rate can be expressed as:

[0105]

[0106] where lost i is the packet loss rate of the i-th path, and wc i is the weight of the i-th video data stream.

[0107] 2. Determine the combined delay.

[0108] The sending device can determine the combined delay based on the delays of the N video data streams. The sending device can average the delays of the N video data streams to determine the combined delay. That is, the combined delay can be expressed as:

[0109]

[0110] where lost i is the delay of the i-th path.

[0111] 3. Determine the combined sending rate.

[0112] The sending device can determine the combined sending rate based on the sending rates of the N video data streams. The sending device can sum up the sending rates of the N video data streams to determine the combined sending rate. That is, the combined sending rate can be expressed as:

[0113] where rate i is the sending rate of the i-th path.

[0114] As can be seen from the above, the combined sending index needs to consider the sending index of each path. Therefore, the result of the combined sending index can reflect the sending status of the overall video data stream. Thus, the recommended bit rate of each video data stream determined by the combined sending index is reliable.

[0115] S304. The sending device determines the combined bit rate based on the combined sending index.

[0116] The sending device can input the determined joint transmission metric into the first congestion control algorithm to obtain the recommended joint code rate targetrate. Among them, the joint code rate can be the code rate that the first congestion control algorithm determines for the expected sending device to use. The first congestion control algorithm can be one of congestion control algorithms such as GCC, BBR, and cubic, which will not be elaborated here.

[0117] S305. The sending device determines the target code rate for each path based on the joint code rate and the expected weights of the N video data streams.

[0118] First, the sending device can determine the recommended code rate for each path based on the joint code rate and the expected weights w of the N video data streams. i The sending device can determine the proportion of each video data stream in the joint code rate as the recommended code rate for each path. The recommended code rate for the i-th path can be expressed as:

[0119] suggestedrate i = targetrate·w i

[0120] where w i is the expected weight of the i-th video data stream, and targetrate is the joint code rate.

[0121] As can be seen from the above, the recommended code rate determined based on the proportion of the expected weight of each video data stream in the joint code rate can distinguish the congestion control situations of different data paths tendentially, so as to effectively divide network transmission resources and improve network efficiency.

[0122] Secondly, the sending device can determine the target code rate based on the recommended code rate of each video data stream. The target code rate can include two types: the target encoding code rate and the target sending rate. The following describes the implementation method for determining the target code rate:

[0123] The sending device can determine the target encoding code rate based on the recommended code rate and the expected encoding code rate. The sending device can determine the target encoding code rate of each video data stream based on the recommended code rate and the expected encoding code rate of each video data stream. Among them, each video data stream can include an expected encoding code rate expectedrate i . That is, the target encoding code rate of each video data stream can be determined as the smaller code rate value between the recommended code rate and the expected encoding code rate of this video data stream. The target encoding code rate targetrate1 of the i-th path i can be expressed as:

[0124] targetrate1 i= min(suggestedrate i , expectedrate i )

[0125] Wherein, suggestedrate i is the suggested bitrate of the i-th path, and expectedrate i is the expected encoding bitrate of the i-th path.

[0126] Exemplarily, when the suggested bitrate of the 3rd path is 2 Mpbs and the expected encoding bitrate is 3 Mpbs, the target encoding bitrate of the 3rd path can be determined to be 2 Mpbs.

[0127] The sending-end device can determine the target sending rate based on the suggested bitrate. The sending-end device can determine the target sending rate based on the suggested bitrate and the size of the buffer. The target sending rate of each video data stream can be determined as the smaller bitrate value between the suggested bitrate of this video data stream and the size of the buffer / congestion window time interval. The target sending rate targetrate2 of the i-th path i can be expressed as:

[0128] targetrate2 i = min(suggestedrate i , buffer i / window i )

[0129] Wherein, suggestedrate i is the suggested bitrate of the i-th path, buffer i is the size of the buffer of the i-th path. window i is the congestion window time interval of the i-th path.

[0130] Exemplarily, when the suggested bitrate of the 1st path is 4 Mpbs, the congestion window time interval is 5, and the size of the buffer is 15, the target sending rate of the 1st path can be determined to be 3 Mpbs.

[0131] In the above embodiments, for the target encoding bitrate, the sending-end device can select the smaller one from the suggested bitrate and the expected encoding bitrate; for the target sending rate, the sending-end device can select the smaller one from the suggested bitrate and the processing rate of the buffer, which can further ensure that the encoding and sending rates are within the congestion control and conform to the processing speed of the current encoder and congestion window, guaranteeing the reliability of processing.

[0132] S306. The sending-end device can adjust the encoding bitrate and / or the sending rate based on the target bitrates of the N video data streams.

[0133] The sending device can adjust the encoding bitrate of each encoder respectively based on the target encoding bitrates of N video data streams, and / or adjust the sending rate of each congestion window based on the target sending rates of the N video data streams. In one case, the sending device can adjust the encoding bitrate of each encoder respectively based on the target encoding bitrates of N video data streams. In another case, the sending device can adjust the sending rate of each congestion window based on the target sending rates of the N video data streams. In yet another case, the sending device can adjust the encoding bitrate of each encoder respectively based on the target encoding bitrates of N video data streams, and adjust the sending rate of each congestion window based on the target sending rates of the N video data streams.

[0134] Specifically, the sending device can adjust the encoding bitrates of the N encoder modules through the joint congestion control module; and / or adjust the window size and interval of the N congestion window modules through the joint congestion control module to adjust the sending rate.

[0135] The sending device can adjust the encoding bitrate of the i-th path based on the target encoding bitrate of the i-th path. When the encoding bitrate of the i-th path is less than the current target encoding bitrate, the current encoding bitrate can be increased; when the encoding bitrate of the i-th path is greater than the current target encoding bitrate, the current encoding bitrate can be decreased. The above adjustment process makes the encoding bitrate of the i-th path as small as or equal to the target encoding bitrate of the i-th path. It should be noted that the above encoding bitrate of the i-th path also needs to be less than or equal to its own expected encoding bitrate.

[0136] The sending device can determine the size and interval of the congestion window of the i-th path based on the target sending rate of the i-th path. When the sending rate corresponding to the size and interval of the window is much less than the target sending rate of the i-th path, the current sending rate of the i-th path can be increased by increasing the size of the window and / or decreasing the window interval; when the sending rate corresponding to the size and interval of the window is much greater than the target sending rate of the i-th path, the current sending rate of the i-th path can be decreased by decreasing the size of the window and / or increasing the window interval. It should be noted that the sending rate of the i-th path above is less than or equal to the target sending rate.

[0137] In the embodiments of the present application, when the target bitrate is determined, the sending rate and / or the encoding bitrate can be further adjusted based on the target bitrate, and specific congestion control can be performed. Thus, congestion control can be performed on the N video data streams through the centrally determined target bitrates of the N video data streams, thereby ensuring the integrity and comprehensiveness of the solution.

[0138] Through the above embodiments, the sending device can determine the target bitrate of each video data stream based on the weights and combined bitrates of different video data streams, and can send data packets based on these target bitrates. Therefore, through the congestion control of multiple data streams in an overall manner, the congestion probability caused by competition of data with the same source and destination can be reduced, and the network efficiency can be improved. Secondly, since the weights of different video data streams are different, it is possible to effectively distinguish which data stream requires more transmission, so that it is possible to preferentially and effectively transmit certain data streams, and the probability of successful transmission of important video data streams can be increased. Moreover, in the process of calculating the target bitrates of each video data stream, the current sending metrics of each stream are considered, and the network conditions of each stream can be taken into account, so as to avoid the imbalance of single video data probability statistics, and further ensure the comprehensiveness and accuracy of the target bitrates.

[0139] Please refer to Figure 5 , such as Figure 5 shown in the schematic diagram of the method flow of another congestion control method disclosed in the embodiments of the present application. Among them, this method can be applied to the sending device. A congestion control method may include the following steps:

[0140] S501. The sending device obtains the sending metrics of N video data streams.

[0141] Among them, the specific description of step S501 can refer to step S301.

[0142] In order to specifically illustrate the above method embodiments, the following is an exemplary description of a congestion control method:

[0143] Exemplarily, Figure 6 is the schematic diagram of the video data flow of another congestion control disclosed in the embodiments of the present application. As Figure 6 shown, the sending device may include 4 encoder modules, 4 congestion window modules, and a joint congestion control module. The 4 video data streams are respectively encoded by 4 encoder modules and sent to the network by 4 congestion window modules respectively. The joint congestion control module can be respectively connected to the 4 encoder modules and the 4 congestion window modules, so as to adjust their encoding bitrates and sending rates. Among them, N is 4.

[0144] S502. The sending device can determine the expected weights of the N video streams based on the expected encoding bitrates of each video data stream.

[0145] Among them, the specific description of step S502 can refer to the relevant description in step S302. The method for the sending device to obtain weights based on the clarity requirements. It should be noted that in this embodiment, the data streams are all video data streams, and the two have the same meaning.

[0146] Exemplarily, Figure 6 The four video data streams shown are all video data collected by four different cameras. After each camera captures video data, the four video streams can be encoded and sent separately. Since the pixels and frames of the images captured by these four cameras are different, some of the four video streams have high clarity and some have low clarity. Therefore, different video streams of different cameras will have different clarity requirements. For example, when the expected encoding bitrate requirement for the first video stream is 1.5 Mpbs, the second is 2.5 Mpbs, the third is 4 Mpbs, and the fourth is 2 Mpbs, the expected weights can be obtained. Then, the expected weight w1 of the first video stream is 0.15; the expected weight w2 of the second video stream is 0.25; the expected weight w3 of the third video stream is 0.4; the expected weight w4 of the fourth video stream is 0.2.

[0147] S503. The sending device determines the joint sending metric based on the sending metrics.

[0148] Among them, the specific description of step S503 can refer to step S303.

[0149] Exemplarily, as Figure 6 shown, the joint packet loss rate, joint delay, and joint sending rate in the four video streams can be determined respectively as:

[0150] When the sending rate of the first video stream is 1.2 Mpbs; the sending rate of the second video stream is 2.6 Mpbs; the sending rate of the third video stream is 3.8 Mpbs; the sending rate of the fourth video stream is 2.4 Mpbs, the calculated weight wc1 of the first video stream can be determined as 0.12; the calculated weight wc2 of the second video stream is 0.26; the calculated weight wc3 of the third video stream is 0.38; the calculated weight wc4 of the fourth video stream is 0.24. After determining the calculated weights of each path, the joint packet loss rate can be determined based on the calculated weight and packet loss rate of each path. When the packet loss rate of the first video stream is 0.01%; the packet loss rate of the second video stream is 0.03%; the packet loss rate of the third video stream is 0.04%; the packet loss rate of the fourth video stream is 0.02%. Based on the above situation, the joint packet loss rate can be determined as lost corp = lost1·wc1 + lost2·wc2 + lost3·wc3 + lost4·wc4 = 0.01% × 0.12 + 0.03% × 0.26 + 0.04% × 0.38 + 0.02% × 0.24 = 0.029%.

[0151] When the latency of the first video stream is 24 ms; the latency of the second video stream is 26 ms; the latency of the third video stream is 18 ms; and the latency of the fourth video stream is 20 ms. Based on the above situation, the combined latency can be determined

[0152] When the transmission rate of the first video stream is 1.2 Mbps; the transmission rate of the second video stream is 2.6 Mbps; the transmission rate of the third video stream is 3.8 Mbps; and the transmission rate of the fourth video stream is 2.4 Mbps. Based on the above situation, the combined transmission rate can determine rate corp = 1.2 + 2.6 + 3.8 + 2.4 = 10 Mbps.

[0153] S504. The sending device determines the combined coding rate based on the combined transmission metrics.

[0154] Among them, the specific description of step S504 can refer to step S304.

[0155] Specifically, the combined transmission metrics are input into the first congestion control algorithm to obtain the combined coding rate. For example, when the combined latency of 24 ms is input into the first congestion control algorithm (GCC algorithm), the obtained combined coding rate is 8 Mbps.

[0156] S505. The sending device determines the recommended coding rate for each path based on the combined coding rate and the expected weights of the N video data streams.

[0157] Among them, the specific description of step S505 can refer to step S305.

[0158] Exemplarily, the recommended coding rate for the first path can be determined as: suggestedrate1 = targetrate · w1 = 8 * 0.15 = 1.2 Mbps; the recommended coding rate for the second path can be determined as: suggestedrate2 = targetrate · w2 = 8 * 0.25 = 2 Mbps; the recommended coding rate for the third path can be determined as: suggestedrate3 = targetrate · w3 = 8 * 0.4 = 3.2 Mbps; the recommended coding rate for the fourth path can be determined as: suggestedrate4 = targetrate · w4 = 8 * 0.2 = 1.6 Mbps.

[0159] S506. The sending device determines the target coding rate for each path based on the recommended coding rate and the expected coding rate of each video data stream.

[0160] Among them, the specific description of step S506 can refer to step S305.

[0161] Exemplarily, as can be seen from step S505, the recommended bitrate for the first channel can be determined as 1.2 Mpbs; the recommended bitrate for the second channel can be determined as: 2 Mpbs; the recommended bitrate for the third channel can be determined as: 3.2 Mpbs; the recommended bitrate for the fourth channel can be determined as: 1.6 Mpbs. On the one hand, the sending device can determine the target encoding bitrate based on the recommended bitrate and the desired encoding bitrate. In the case where the desired encoding bitrate of the first video stream is 1.5 Mpbs; the desired encoding bitrate of the second video stream is 2.1 Mpbs; the desired encoding bitrate of the third video stream is 3.0 Mbps; the desired encoding bitrate of the fourth video stream is 2.0 Mbps. It can be determined that the target encoding bitrate of the first video stream is min(1.2, 1.5) = 1.2 Mpbs; the target encoding bitrate of the second video stream is min(2, 2.1) = 2 Mpbs; the target encoding bitrate of the third video stream is min(3.2, 3.0) = 3.0 Mpbs; the target encoding bitrate of the fourth video stream is min(1.6, 2.0) = 1.6 Mpbs. On the other hand, the sending device can determine the target encoding bitrate based on the recommended bitrate, the congestion window time interval, and the size of the buffer. In the case where the congestion window time interval of the first video stream is 5 ms, the size of the buffer is 10,000 bits, 10,000 bits / 0.005 s = 2 Mbps; the congestion window time interval of the second video stream is 8 ms, the size of the buffer is 16,000 bits, 16,000 bits / 0.008 s = 2 Mbps; the congestion window time interval of the third video stream is 4 ms, the size of the buffer is 16,000 bits, 16,000 bits / 0.004 s = 4 Mbps; the congestion window time interval of the fourth video stream is 4 ms, the size of the buffer is 8,000 bits, 8,000 bits / 0.004 s = 2 Mbps, it can be determined that the target sending rate of the first video stream is min(1.2, 2) = 1.2 Mpbs; the target sending rate of the second video stream is min(2, 2) = 2 Mpbs; the target sending rate of the third video stream is min(3.2, 4.0) = 3.2 Mpbs; the target sending rate of the fourth video stream is min(1.6, 2.0) = 1.6 Mpbs.

[0162] S507. The sending device can adjust the encoding bitrate and / or the sending rate based on the recommended bitrates of the N video data streams.

[0163] Among them, the specific description of step S507 can refer to step S306 and will not be elaborated here.

[0164] Please refer to Figure 7 , Figure 7It is a schematic structural diagram of a congestion control device disclosed in an embodiment of the present application. Among them, the congestion control device may include:

[0165] A first determination unit 701, configured to determine the expected weights of N video data streams, where the source addresses and destination addresses of the N video data streams are the same, and N is an integer greater than 1;

[0166] A second determination unit 702, configured to determine a combined transmission metric based on the transmission metrics of the N video data streams, where the transmission metrics include one or more of packet loss rate, latency, and transmission rate;

[0167] A third determination unit 703, configured to determine a combined code rate based on the combined transmission metric;

[0168] A fourth determination unit 704, configured to determine the target code rate of each of the N video data streams based on the combined code rate and the expected weights.

[0169] As a possible implementation manner, the target code rate includes a target encoding code rate and a target transmission rate, and the fourth determination unit 704 is specifically configured to:

[0170] Determine the recommended code rate of each of the N video data streams based on the combined code rate and the expected weights;

[0171] Determine the N target encoding code rates based on the recommended code rates and the expected encoding code rates of the N video data streams, where the N video data streams correspond one-to-one to the N target encoding code rates;

[0172] Determine the target transmission rate based on the recommended code rates of the N video data streams, where the N video data streams correspond one-to-one to the N target transmission rates;

[0173] The device further includes an adjustment unit 705, configured to adjust the corresponding encoding code rate based on the target encoding code rate of the N video data streams;

[0174] It is further configured to adjust the corresponding transmission rate based on the target transmission rate of the N video data streams.

[0175] As a possible implementation manner, the first determination unit 701 is specifically configured to:

[0176] Determine the expected encoding code rates of N video data streams, where the N expected encoding code rates correspond one-to-one to the N video data streams;

[0177] Determine the proportion of the expected encoding code rate of the i-th video data stream in the sum of the expected encoding code rates of all N video data streams as the expected weight of the i-th video data stream.

[0178] As a possible implementation manner, when the sending metric includes the packet loss rate, the second determining unit 702 is specifically configured to:

[0179] Determine the weighted average of the N packet loss rates and N calculation weights of the N video data streams as the joint packet loss rate, where the N calculation weights correspond to the N video data streams one by one;

[0180] When the sending metric includes the delay, the second determining unit 702 is further specifically configured to:

[0181] Determine the average of the delays of the N video data streams as the joint delay;

[0182] When the sending metric includes the sending rate, the second determining unit 702 is further specifically configured to:

[0183] Determine the sum of the sending rates of the N video data streams as the joint sending rate.

[0184] As a possible implementation manner, before the second determining unit 702 determines the weighted average of the N packet loss rates and N calculation weights of the N video data streams as the joint packet loss rate, it is further configured to:

[0185] Determine the expected weight of the i-th video data stream as the calculation weight of the i-th path; or,

[0186] Determine the proportion of the actual coding bit rate of the i-th video data stream in the sum of the actual coding bit rates of all N paths as the calculation weight of the i-th path, where the N actual coding bit rates correspond to the N video data streams one by one;

[0187] Or, determine the proportion of the sending rate of the i-th video data stream in the sum of the sending rates of all N paths as the calculation weight of the i-th path, where the N sending rates correspond to the N video data streams one by one.

[0188] As a possible implementation manner, the third determining unit 703 is specifically configured to input the joint sending metric into a first congestion control algorithm to obtain a joint bit rate.

[0189] Based on the above description, please refer to Figure 8 , Figure 8 is a schematic structural diagram of a congestion control device disclosed in an embodiment of the present application. As Figure 8As shown, the device may include a processor 801, a memory 802, an input interface 803, an output interface 804, and a bus 805. The memory 802 may exist independently and be connected to the processor 801 through the bus 805. Among them, the input interface 803 is used to receive information from other devices, and the output interface 804 is used to output, schedule, or send information to other devices. The memory 802 may also be integrated with the processor 801. Among them, the bus 805 is used to implement the connection between these components.

[0190] In one embodiment, the congestion control device may be a sending device or a module (such as a chip) within the sending device. When the computer program instructions stored in the memory 802 are executed, the processor 801 is used for the first determination unit 701, the second determination unit 704, the third determination unit 703, and the fourth determination unit 704 to perform the operations performed in the above embodiments. The input interface 803 is used to receive information from other devices, and the output interface 804 is used to perform the operations performed by the adjustment unit 705 in the above embodiments. The above sending device or the module within the sending device may also be used to perform the above Figure 3 and Figure 5 various methods performed by the sending device or the sending device in the method embodiments, which will not be elaborated here.

[0191] In one embodiment, the congestion control device may be a sending device or a module (such as a chip) within the sending device. When the computer program instructions stored in the memory 802 are executed, the processor 801 is used to control the first determination unit 701, the second determination unit 704, the third determination unit 703, and the fourth determination unit 704 to perform the operations performed in the above embodiments. The input interface 803 is used to receive information from other devices, and the output interface 804 is used to perform the operations performed by the adjustment unit 705 in the above embodiments. The above sending device or the module within the sending device may also be used to perform the above Figure 3 and Figure 5 various methods performed by the sending device or the sending device in the method embodiments, which will not be elaborated here.

[0192] The embodiments of the present application also disclose a computer-readable storage medium, on which instructions are stored, and when the instructions are executed, the methods in the above method embodiments are performed.

[0193] The embodiments of the present application also disclose a computer program product including instructions, and when the instructions are executed, the methods in the above method embodiments are performed.

[0194] The specific embodiments described above further elaborate on the purpose, technical solutions, and beneficial effects of the present application. It should be understood that the above description is only for the specific embodiments of the present application and is not used to limit the protection scope of the present application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present application shall be included within the protection scope of the present application.

[0195] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive), etc.

[0196] Those of ordinary skill in the art can understand all or part of the processes in the above-described method embodiments. These processes can be completed by relevant hardware instructed by a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above-described method embodiments. The foregoing storage medium includes various media that can store program codes, such as ROM or random access memory RAM, magnetic disks, or optical discs.

Claims

1. A congestion control method, characterized in that, Including: Determine the expected weights of N video data streams, where the source addresses and destination addresses of the N video data streams are the same, and N is an integer greater than 1; Determine a combined transmission metric based on the transmission metrics of the N video data streams, where the transmission metrics include one or more of packet loss rate, latency, and transmission rate; Determine a combined bitrate based on the combined transmission metric; Determine the target bitrate of each of the N video data streams based on the combined bitrate and the expected weights; Wherein, when the transmission metric includes a packet loss rate, determining the combined transmission metric based on the transmission metrics of the N video data streams includes: Determine the combined packet loss rate by weighted averaging the N packet loss rates and N calculation weights of the N video data streams, where the N calculation weights correspond one-to-one to the N video data streams; When the transmission metric includes latency, determining the combined transmission metric based on the transmission metrics of the N video data streams, determining the combined transmission metric based on the transmission metrics of the N video data streams includes: Determine the combined latency by averaging the latencies of the N video data streams; When the transmission metric includes transmission rate, determining the combined transmission metric based on the transmission metrics of the N video data streams, determining the combined transmission metric based on the transmission metrics of the N video data streams includes: Determine the combined transmission rate by summing the transmission rates of the N video data streams.

2. The method according to claim 1, wherein The target bitrate includes a target encoding bitrate and a target transmission rate. Determining the target bitrate of each of the N video data streams based on the combined bitrate and the expected weights includes: Determine the recommended bitrate of each of the N video data streams based on the combined bitrate and the expected weights; Determine the N target encoding bitrates based on the recommended bitrates and the expected encoding bitrates of the N video data streams, where the N video data streams correspond one-to-one to the N target encoding bitrates; Determine the target transmission rate based on the recommended bitrates of the N video data streams, where the N video data streams correspond one-to-one to the N target transmission rates; The method further includes: Adjust the corresponding encoding bitrate based on the target encoding bitrate of the N video data streams; Adjust the corresponding transmission rate based on the target transmission rate of the N video data streams.

3. The method according to claim 1, wherein Determining the expected weights of the N video data streams includes: Determine the expected encoding bitrates of the N video data streams, where the N expected encoding bitrates correspond one-to-one to the N video data streams; Determine the proportion of the expected encoding bitrate of the i-th video data stream in the sum of all expected encoding bitrates of the N video data streams as the expected weight of the i-th video data stream.

4. The method according to any one of claims 1 to 3, characterized in that, Before determining the combined packet loss rate by weighted averaging the N packet loss rates and N calculation weights of the N video data streams, the method further includes: Determine the expected weight of the i-th video data stream as the calculation weight of the i-th video data stream; or, Determine the calculation weight of the i-th video data stream as the ratio of the actual coding bitrate of the i-th video data stream to the sum of the actual coding bitrates of all N video data streams, where the N actual coding bitrates correspond one-to-one with the N video data streams; or, Determine the calculation weight of the i-th video data stream as the ratio of the sending rate of the i-th video data stream to the sum of the sending rates of all N video data streams, where the N sending rates correspond one-to-one with the N video data streams.

5. The method according to any one of claims 1 to 3, characterized in that, The determining the joint bitrate based on the joint sending metric includes: Input the joint sending metric into the first congestion control algorithm to obtain the joint bitrate.

6. A congestion control device, characterized in that, It includes: A first determining unit for determining the expected weights of N video data streams with the same source address and destination address, where N is an integer greater than 1; A second determining unit for determining a joint sending metric based on the sending metrics of the N video data streams, where the sending metrics include one or more of packet loss rate, latency, and sending rate; A third determining unit for determining the joint bitrate based on the joint sending metric; A fourth determining unit for determining the target bitrate of each video data stream in the N video data streams based on the joint bitrate and the expected weights; Wherein, when the sending metric includes the packet loss rate, the second determining unit is configured to: Determine the weighted average of the N packet loss rates and the N calculation weights of the N video data streams as the joint packet loss rate, where the N calculation weights correspond one-to-one with the N video data streams; When the sending metric includes latency, the second determining unit is configured to: Determine the average of the latencies of the N video data streams as the joint latency; When the sending metric includes the sending rate, the second determining unit is configured to: Determine the sum of the sending rates of the N video data streams as the joint sending rate.

7. A congestion control device, characterized in that, It includes: A processor and a memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or computer instructions, and when the computer program or computer instructions are run, the method according to any one of claims 1-5 is implemented.

9. A computer program product, characterized in that, The computer program product includes computer program code, and when the computer program code is run, the method according to any one of claims 1-5 is executed.

Images