CN115277654A - Bandwidth resource distribution system of RTC system - Google Patents
Bandwidth resource distribution system of RTC system Download PDFInfo
- Publication number
- CN115277654A CN115277654A CN202210855229.8A CN202210855229A CN115277654A CN 115277654 A CN115277654 A CN 115277654A CN 202210855229 A CN202210855229 A CN 202210855229A CN 115277654 A CN115277654 A CN 115277654A
- Authority
- CN
- China
- Prior art keywords
- bandwidth
- video
- packet loss
- retransmission
- allocated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012544 monitoring process Methods 0.000 claims abstract description 30
- 238000013468 resource allocation Methods 0.000 claims abstract description 19
- 238000012937 correction Methods 0.000 claims description 87
- 238000004364 calculation method Methods 0.000 claims description 35
- 238000000034 method Methods 0.000 claims description 25
- 230000005540 biological transmission Effects 0.000 claims description 12
- 230000008569 process Effects 0.000 claims description 6
- WPPDXAHGCGPUPK-UHFFFAOYSA-N red 2 Chemical compound C1=CC=CC=C1C(C1=CC=CC=C11)=C(C=2C=3C4=CC=C5C6=CC=C7C8=C(C=9C=CC=CC=9)C9=CC=CC=C9C(C=9C=CC=CC=9)=C8C8=CC=C(C6=C87)C(C=35)=CC=2)C4=C1C1=CC=CC=C1 WPPDXAHGCGPUPK-UHFFFAOYSA-N 0.000 claims description 6
- 101150113227 RED3 gene Proteins 0.000 claims description 3
- 230000000875 corresponding effect Effects 0.000 description 29
- 230000008859 change Effects 0.000 description 6
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 4
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 241000251468 Actinopterygii Species 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000007619 statistical method Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/52—Queue scheduling by attributing bandwidth to queues
- H04L47/522—Dynamic queue service slot or variable bandwidth allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2385—Channel allocation; Bandwidth allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention relates to a bandwidth resource allocation system of an RTC system, which comprises a network state monitor, a bandwidth resource allocation module and a bandwidth resource allocation module, wherein the network state monitor is used for receiving and analyzing network state monitoring data in real time to obtain a current network state and an estimated bandwidth; the bandwidth allocation decision maker requests the network state monitor to inquire the current network state at regular time, acquires the estimated bandwidth in the current network state, generates an initial bandwidth allocation decision according to the estimated bandwidth in the current network state and outputs the initial bandwidth allocation decision to the sending end, and after the sending end operates for a period of time according to the initial bandwidth allocation decision, synthesizes the current network state and the result fed back by the decision result monitor to generate a new bandwidth allocation decision and outputs the new bandwidth allocation decision to the sending end so that the sending end operates according to the new bandwidth allocation strategy; and the decision result monitor feeds back the comparison result of the new call quality and the initial call quality to the bandwidth allocation decision device. The system improves definition and fluency on the premise of ensuring real-time performance of the RTC.
Description
Technical Field
The present invention relates to the field of communications, and in particular, to a bandwidth resource allocation system for an RTC system.
Background
The RTC real-time communication is short for real-time audio and video. In recent years, with the continuous development of network and audio-video technologies, RTCs have been widely applied in remote finance, remote education, remote medical treatment, internet social contact and other scenes. When the advanced technology brings huge growth to online scenes, the advanced technology also faces higher and higher experience requirements of users, lower delay, higher image quality and smoother performance, namely, the three user experience influence factors are corresponding to three core indexes of the RTC, namely, real-time performance, definition and fluency.
Three core indices for RTC: among the three, the real-time performance, the definition and the fluency, the fish and the bear paw are not available, and scenes with higher real-time performance requirements may sacrifice the definition to ensure low delay; and scenes with high definition requirements can be exchanged for high-quality audio and video data with certain time delay. In real life, the meeting environment is very complex, including various complex network environments. In order to provide a good audio-video conferencing experience, we usually need to make decisions based on real-time network status to reach the best user experience.
The existing method obtains a table firstly according to experience, and in practice, dynamically checks the table by combining with the network condition, allocates the coding rate of video and audio, and realizes the bandwidth pre-allocation of Forward error correction coding (FEC for short) and packet loss retransmission (NACK for short); the FEC recovers the lost part of information through transmitted redundant information without requiring retransmission of an information source, so as to achieve the purpose of low delay, NACK is a packet that the receiving end does not receive the protocol convention by informing the sending end, so as to implement retransmission of a data packet that is not sent, and belongs to backward error correction. At the time of bandwidth allocation, some limiting measures are taken, such as the code rate for FEC and NACK must not exceed a certain threshold of the coding rate. However, the existing bandwidth allocation method has the following limitations: 1. the previous bandwidth state is not considered in bandwidth allocation, and global consideration is lacked. Switching encoders and sending key frames causes performance loss when resolution changes; 2. when the available bandwidth of NACK is distributed, based on the statistics of the past state, the actual coding code rate is not considered, and the problems of bandwidth waste or insufficient flow rate probably occur in the actual use; 3. the same strategy is used for different types of networks, the real-time performance of the RTC is important, and the influence of network delay is fully considered when the flow is decided to be retransmitted actively. Relative to a low-delay network, a high-delay network should place the emphasis on packet loss resistance on an active retransmission packet; 4. and the whole decision system does not form a closed loop due to the lack of processing of decision feedback results. Further improvements are needed for this purpose.
Disclosure of Invention
The technical problem to be solved by the present invention is to provide a bandwidth resource allocation system of an RTC system, which can improve definition and smoothness on the premise of ensuring real-time performance of the RTC, in view of the above prior art.
The technical scheme adopted by the invention for solving the technical problems is as follows: a bandwidth resource allocation system of an RTC system, comprising: a network state monitor, a bandwidth allocation decision maker and a decision result monitor;
the network state monitor is used for receiving the network state monitoring data in real time, analyzing the network state monitoring data to obtain the current network state and outputting the estimated bandwidth in the current network state;
the bandwidth allocation decision maker regularly requests the network state monitor to inquire the current network state, acquires the estimated bandwidth in the current network state, generates an initial bandwidth allocation decision according to the estimated bandwidth in the current network state and outputs the initial bandwidth allocation decision to the sending end, and after the sending end operates for a period of time according to the initial bandwidth allocation decision, integrates the current network state and the result fed back by the decision result monitor to generate a new bandwidth allocation decision and outputs the new bandwidth allocation decision to the sending end so that the sending end operates according to the new bandwidth allocation strategy;
and the decision result monitor is used for acquiring the initial call quality after the sending end operates for a period of time according to the initial bandwidth allocation decision, acquiring the new call quality after the sending end operates for a period of time according to the new bandwidth allocation strategy, comparing the new call quality with the initial call quality, and feeding back the comparison result of the new call quality and the initial call quality to the bandwidth allocation decision maker.
And according to different requirements of the conference, the bandwidth allocation decision-making device sequentially allocates the estimated bandwidth in the current network state to the audio, the screen sharing and the video according to the sequence.
Further, the specific steps of the bandwidth allocation decision maker for generating a new decision are as follows:
step 1-1, determining an audio sending strategy according to current network state monitoring data to obtain a bandwidth required by audio;
step 1-2, determining whether to start passive packet loss retransmission or not by combining previous network state monitoring data and the round-trip delay condition in the current network state;
step 1-3, determining a screen sharing strategy according to the current network state monitoring data and the starting state of the passive packet loss retransmission, and obtaining the bandwidth required by screen sharing and the passive packet loss retransmission bandwidth required by screen sharing;
step 1-4, determining a video sending strategy according to the current network state monitoring data and the starting state of the passive packet loss retransmission, and obtaining the bandwidth required by the video and the passive packet loss retransmission bandwidth required by the video;
step 1-5, confirming the maximum bandwidth available for passive packet loss retransmission; the method comprises the following specific steps:
subtracting the bandwidth required by audio, the bandwidth required by screen sharing and the bandwidth required by video from the estimated bandwidth in the current network state to obtain the residual bandwidth;
judging whether the residual bandwidth is larger than the sum of the passive packet loss retransmission bandwidth required by screen sharing and the passive packet loss retransmission bandwidth required by the video, if so, taking the residual bandwidth as the maximum available bandwidth for the final passive packet loss retransmission; if not, taking the result of the residual bandwidth xk as the maximum available bandwidth for the final passive packet loss retransmission;
step 1-6, taking the bandwidth required by the audio, the bandwidth required by screen sharing, the passive packet loss retransmission bandwidth required by screen sharing, the bandwidth required by video, the passive packet loss retransmission bandwidth required by video and the maximum bandwidth available for passive packet loss retransmission as a new bandwidth allocation decision;
step 1-7, inquiring the opinion of the decision result monitor, if the call quality corresponding to the new bandwidth allocation strategy fed back by the decision result monitor is superior to the call quality corresponding to the last bandwidth allocation strategy, the bandwidth allocation decision maker executes the new decision according to the bandwidth allocation in the step 1-6 through the sending end; and when the call quality corresponding to the new bandwidth allocation strategy is lower than the call quality corresponding to the last bandwidth allocation strategy fed back by the decision result monitor, the bandwidth allocation decision-making device informs the sending end to execute according to the last bandwidth allocation strategy.
Specifically, the specific steps of determining the audio sending policy in step 1-1 are as follows:
step 1-1a, determining the forward error correction coding redundancy of pre-allocated audio and the number of active retransmission packets according to the packet loss rate of the current network;
step 1-1b, calculating bandwidth Br required by pre-distributing audio1;
Br1=codec1*(1+K1)*(1+RED1)
Wherein, codec1Representing the code rate, K, of the audio coding1The amount of forward error correction coding redundancy for pre-allocated audio, depending on whether forward error correction coding is turned on, K1=100% or 0; RED1Representing the number of active retransmission packets of pre-allocated audio;
step 1-1c, judging whether the estimated bandwidth in the current network state is enough to pre-allocate the forward error correction coding redundancy of the audio and actively resendingBandwidth Br required by the number of packets1If yes, pre-allocating the bandwidth Br required by the audio1As the current audio sending strategy, and the step 1-1d is carried out; if not, gradually reducing the number of active retransmission packets of the pre-allocated audio, and recalculating the bandwidth Br required by the pre-allocated audio according to the formula in the step 1-1b1Making newly calculated bandwidth Br required for pre-allocation of audio estimates1Less than the estimated bandwidth in the current network state, and then estimating the newly calculated bandwidth Br required for pre-allocation of audio1As the current audio sending strategy, and the step 1-1d is carried out;
step 1-1d, outputting the bandwidth required by the audio;
specifically, the specific method for determining the forward error correction coding redundancy and the number of active retransmission packets of the pre-allocated audio in step 1-1a is as follows:
judging whether the packet loss rate of the current network is greater than a first threshold value, if so, opening forward error correction coding of the pre-distributed audio, and setting the forward error correction coding redundancy of the pre-distributed audio to be 100%; if not, not opening the forward error correction coding, and setting the forward error correction coding redundancy of the pre-allocated audio to be 0;
in addition, whether the packet loss rate of the current network is greater than a second threshold value is judged, if yes, active retransmission of pre-allocated audio is started, and the rule that the packet loss rate is gradually increased and the number of active retransmission packets is gradually increased is followed, so that the number of active retransmission packets is determined according to the packet loss rate of the current network; if not, not opening the active retransmission, and the number of the active retransmission packets is 0.
Further, the method for confirming whether the passive packet loss retransmission is started in step 1-2 is as follows:
judging whether the round-trip delay time in the current network state is greater than a preset time threshold, if so, not starting passive packet loss retransmission, and if not, starting passive packet loss retransmission;
if the passive packet loss retransmission is not started, setting the passive packet loss retransmission coefficient in the current network state as 1;
if the passive packet loss retransmission is started, setting a passive packet loss retransmission coefficient in the current network state as NackCoefficient (sendTimes);
the calculation formula of NackCoefficient (sendTimes) is:
NackCoefficient(sendTimes)=1+losssendTimes
wherein loss represents the packet loss rate, and sendTimes represents the number of passive packet loss retransmissions.
Further, the specific steps of determining the screen sharing policy in the steps 1 to 3 are as follows:
step 1-3a, determining the forward error correction coding redundancy quantity shared by a pre-allocated screen and the quantity of active retransmission packets according to the packet loss rate and the passive packet loss retransmission state in the current network state;
step 1-3b, calculating bandwidth Br required by sharing pre-allocated screen2(ii) a The calculation formula is as follows:
Br2=codec2*NackCoefficient(1+RED2)*(1+K2)*(1+RED2)
in the formula: codec2Representing screen-shared code rate codec2Having an initial preset value, RED2Indicates the number of active retransmission packets shared by the pre-allocated screen, nackCoefficient (1 + RED)2) For passive packet loss retransmission coefficient, when passive packet loss retransmission state is not started, nackCoefficient (1 +RED)2) =1, when passive packet loss retransmission state is started, 1+ RED2Substituting the sendTimes as the packet loss retransmission times into a calculation formula of the passive packet loss retransmission coefficient; k2Representing the amount of forward error correction coding redundancy of the pre-allocated screen share;
step 1-3c, subtracting the bandwidth required by the audio from the estimated bandwidth in the current network state to obtain a first remaining available bandwidth, and judging whether the first remaining available bandwidth is enough to pre-allocate the bandwidth Br required by the screen sharing2If yes, the bandwidth Br required by pre-allocation screen sharing is met2As the current screen sharing sending strategy, and turning to the step 1-3e; if not, turning to the step 1-3d;
step 1-3d, adjusting the bandwidth required by the sharing of the pre-allocated screen in sequence according to the following steps:
1-3d (1), reducing the screen sharing coding rate;
when the coding code rate of the screen sharing is gradually reduced, recalculating the bandwidth Br required by the pre-allocated screen sharing according to the formula of the step 1-3b2To make the pre-allocated screen share the required bandwidth Br2If the bandwidth is less than the first residual available bandwidth, the recalculated pre-allocated screen is shared with the required bandwidth Br2As the current screen sharing sending strategy, and the step 1-3e is carried out; if the coding code rate of the screen sharing is reduced to the minimum value, the bandwidth Br required by the pre-distributed screen sharing is obtained through recalculation2If the first remaining available bandwidth is still larger than or equal to the first remaining available bandwidth, the step 1-3d (2) is carried out;
step 1-3d (2), reducing the number of active retransmission packets shared by the screen, and resetting the coding rate shared by the screen to an initial value;
after the number of active retransmission packets shared by the screen is reduced each time, the coding code rate shared by the screen is gradually reduced, and then the bandwidth Br required by the pre-distributed screen sharing is recalculated according to the formula of the step 1-3b2Until the recalculated pre-allocated screen shares the required bandwidth of Br2If the bandwidth is less than the first residual available bandwidth, the recalculated pre-allocated screen is shared with the required bandwidth Br2As the current screen sharing sending strategy, and turning to the step 1-3e; if not, turning to the step 1-3d (3);
step 1-3d (3), reducing the forward error correction coding redundancy shared by the pre-allocated screen, and resetting the coding code rate shared by the screen to the initial value;
after the forward error correction coding redundancy amount shared by the pre-allocated screen is reduced each time, the coding code rate shared by the screen is gradually reduced, the number of active retransmission packets shared by the screen is the minimum value, and then the bandwidth Br required by the pre-allocated screen sharing is recalculated according to the formula of the step 1-3b2Until the recalculated pre-allocated screen shares the required bandwidth Br2If the bandwidth is less than the first residual available bandwidth, the recalculated pre-allocated screen is shared with the required bandwidth Br2Sending policies as current screen sharingSlightly, and turning to the step 1-3e; if the forward error correction coding redundancy shared by the pre-allocated screens is reduced to the minimum value and the coding code rate shared by the screens is reduced to the minimum value, the bandwidth Br required by the pre-allocated screens after recalculation2If the bandwidth is still larger than or equal to the first residual available bandwidth, the bandwidth Br required by sharing the pre-allocated screen obtained by the last sequential calculation is used2As the current screen sharing sending strategy, and turning to the step 1-3e;
step 1-3e, outputting bandwidth required by screen sharing and passive packet loss retransmission bandwidth required by screen sharing;
the bandwidth required by screen sharing is the screen sharing coding code rate, the front and back error correction coding redundancy of pre-distribution screen sharing and the number of active retransmission packets in the current screen sharing transmission strategy are substituted into Br2Obtained by calculation in a formula;
passive packet loss retransmission bandwidth Br required by screen sharingnack1The calculation formula is as follows:
Brnack1=codec2*(NackCoefficient(1+RED2)-1);
the passive packet loss retransmission bandwidth required by the screen sharing in the step is the screen sharing coding code rate and the active retransmission packet quantity in the current screen sharing sending strategy and substituted into Brnack1And calculating the formula.
Specifically, the specific method for determining the forward error correction coding redundancy and the number of active retransmission packets for pre-allocating screen sharing in step 1-3a is as follows:
setting the lowest value of the forward error correction coding redundancy shared by the pre-allocated screens as Lmin, and setting the highest value of the forward error correction coding redundancy shared by the pre-allocated screens as 100%; determining the forward error correction coding redundancy shared by the pre-allocated screen according to the packet loss rate of the current network according to the rule that the forward error correction coding redundancy shared by the pre-allocated screen is gradually increased when the packet loss rate is gradually increased;
if the packet loss rate of the current network is greater than a third threshold value, opening active retransmission shared by the pre-allocated screens, and following the rule that the packet loss rate is gradually increased and the number of the active retransmission packets shared by the pre-allocated screens is gradually increased, so that the number of the active retransmission packets shared by the pre-allocated screens is determined according to the packet loss rate of the current network; if not, not opening the active retransmission shared by the pre-allocation screen, and the number of the active retransmission packets shared by the pre-allocation screen is 0.
Further, the video sending policy determination in steps 1 to 4 specifically includes:
step 1-4a, determining the forward error correction coding redundancy and the number of active retransmission packets of a pre-distributed video according to the packet loss rate and the passive packet loss retransmission state of the current network;
step 1-4b, calculating bandwidth Br required by pre-distribution video3(ii) a The calculation formula is as follows:
Br3=codec3*NackCoefficient(1+RED3)*(1+K3)*(1+RED3)
in the formula: codec3Representing the coding rate, codec, of the video3Has an initial value; RED3The active retransmission packet number of the pre-allocated video is represented, nackCoefficient (1 + RED 3) is a passive packet loss retransmission coefficient, and when the passive packet loss retransmission state is not started, nackCoefficient (1 + RED 3) =1; when the passive packet loss retransmission state is started, substituting 1+ RED3 as the active packet loss retransmission times sendTimes into a calculation formula of the passive packet loss retransmission coefficient; k3Representing the amount of forward error correction coding redundancy of the pre-allocated video;
1-4c, subtracting the bandwidth required by screen sharing from the first residual available bandwidth to obtain a second residual available bandwidth; and determines whether the second remaining available bandwidth is sufficient to pre-allocate the bandwidth Br required by the video3If yes, the bandwidth Br required by the pre-distributed video is satisfied3As the current video sending strategy, the method is shifted to the step 1-4e; if not, turning to the step 1-4d;
step 1-4d, adjusting the bandwidth required by the pre-distributed video in sequence according to the following steps:
1-4d (1), reducing the coding rate of the video;
if the coding code rate of the video is gradually reduced, recalculating according to the formula of the step 1-4bBandwidth Br required for pre-distributing video3Bandwidth Br required to pre-allocate video3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the encoding code rate of the video is reduced to the minimum value, the bandwidth Br required by the pre-distributed video after recalculation3If the bandwidth is still larger than or equal to the second remaining available bandwidth, the step 1-4d (2) is carried out;
step 1-4d (2), reducing the number of active retransmission packets of the video, and resetting the coding code rate of the video to an initial value;
after the number of active retransmission packets of the video is reduced each time, the coding code rate of the video is adjusted, and then the bandwidth Br required by the pre-distributed video is recalculated according to the formula of the step 1-4b3Until the bandwidth Br required by the recalculated pre-distributed video3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the number of the active retransmission packets of the video is reduced to the minimum value and the coding code rate of the video is reduced to the minimum value, the bandwidth Br required by the pre-distributed video after recalculation is carried out3If the bandwidth is still larger than or equal to the second remaining available bandwidth, the step 1-4d (4) is carried out;
step 1-4d (4), reducing the redundancy of forward error correction coding of the pre-distributed video, and resetting the coding rate of the video to an initial value;
after the forward error correction coding redundancy of the pre-distributed video is reduced each time, the coding rate of the video is adjusted, and then the bandwidth Br required by the pre-distributed video is recalculated according to the formula of the step 1-4b3Until the bandwidth Br required for pre-distributing the video is recalculated3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the redundancy of the forward error correction coding of the pre-distributed video is reduced to the minimum value and the coding code rate of the video is reduced to the minimum value, recalculating the bandwidth Br required by the pre-distributed video3If the bandwidth is still larger than or equal to the second residual available bandwidth, the bandwidth Br required by the pre-distributed video obtained by the final sequential calculation is used3As the current video sending strategy, and the step 1-4e is carried out;
step 1-4e, outputting bandwidth required by the video and passive packet loss retransmission bandwidth required by the video;
the bandwidth required by the video is the code rate in the current video transmission strategy, the front and back error correction coding redundancy of the pre-distributed video and the number of active retransmission packets are substituted into Br3Obtained by calculation in a formula;
passive packet loss retransmission bandwidth Br required by videonack2The calculation formula is as follows:
Brnack2=codec3*(NackCoefficient(1+RED3)-1);
the passive packet loss retransmission bandwidth required by the video in the step is the video coding code rate and the number of active retransmission packets in the current video transmission strategy, and the bandwidth is substituted into Brnack2And calculating the formula.
Further, the working process of the decision result monitor comprises the following specific steps:
step 2-1, recording a new bandwidth allocation strategy and call quality corresponding to the new bandwidth allocation strategy, and recording a last bandwidth allocation strategy of the new bandwidth allocation strategy and call quality corresponding to the last bandwidth allocation strategy;
step 2-2, comparing the call quality corresponding to the last bandwidth allocation strategy with the call quality corresponding to the new bandwidth allocation strategy, and judging whether the call quality corresponding to the new bandwidth allocation strategy is inferior to the call quality corresponding to the last bandwidth allocation strategy or not, if so, outputting the call quality corresponding to the new bandwidth allocation strategy which is inferior to the call quality corresponding to the last bandwidth allocation strategy; if not, the call quality corresponding to the new bandwidth allocation strategy is output to be superior to the call quality corresponding to the last bandwidth allocation strategy.
Compared with the prior art, the invention has the advantages that: a bandwidth allocation process of a sending end is constructed into a complete closed-loop system, and a network state monitor, a bandwidth allocation decision maker and a decision result monitor are introduced, so that decision is more intelligent and stable; in addition, the definition and the fluency are improved on the premise of ensuring the real-time performance of the RTC according to the network state change and the self-adaptive generation bandwidth allocation decision of the effective strategy.
Drawings
FIG. 1 is a schematic block diagram of a bandwidth resource allocation system of an RTC system according to an embodiment of the present invention;
FIG. 2 is a flow chart illustrating operation of the network status monitor of FIG. 1;
fig. 3 is a flow chart of the operation of the bandwidth allocation decider of fig. 1.
Detailed Description
The invention is described in further detail below with reference to the accompanying examples.
As shown in fig. 1, the bandwidth resource allocation system of the RTC system in this embodiment includes a network status monitor, a bandwidth allocation decider, and a decision result monitor.
The network state monitor is used for receiving the network state monitoring data in real time, analyzing the network state monitoring data to obtain the current network state and outputting the estimated bandwidth in the current network state; the bandwidth allocation decision-making device requests the network state monitor to inquire the current network state at regular time, acquires the estimated bandwidth in the current network state, generates an initial bandwidth allocation decision according to the estimated bandwidth in the current network state and outputs the initial bandwidth allocation decision to the sending end, and after the sending end operates for a period of time according to the initial bandwidth allocation decision, synthesizes the current network state and the result fed back by the decision result monitor to generate a new bandwidth allocation decision and outputs the new bandwidth allocation decision to the sending end so that the sending end operates according to the new bandwidth allocation strategy; the decision result monitor acquires the initial call quality after the sending end operates for a period of time according to the initial bandwidth allocation decision, acquires the new call quality after the sending end operates for a period of time according to the new bandwidth allocation strategy, compares the new call quality with the initial call quality, and feeds back the comparison result of the new call quality and the initial call quality to the bandwidth allocation decision maker.
The network state monitor is responsible for receiving the network state monitoring data, preprocessing the network state monitoring data, and finally evaluating the network state and feeding back the network state monitoring data to the bandwidth allocation decision maker; the bandwidth allocation decision maker is a core module of the whole system and generates a new bandwidth allocation strategy by combining the current network state and the currently effective and executing bandwidth allocation strategy. The decision result monitor is used for observing the call quality and judging the effect of the bandwidth allocation strategy, so that the whole decision process forms a closed loop to achieve the purpose of optimal decision.
The network state monitor mainly has the functions of reducing errors in network state statistics, avoiding fluctuation of a bandwidth allocation strategy caused by noise, reducing unnecessary changes of the bandwidth allocation strategy and enabling changes of the bandwidth allocation strategy of a sending end to be more accurate and stable; in addition, the network state monitoring data comprises available bandwidth, packet loss rate and round-trip delay time, and an observation window with limited length is respectively distributed in the network state monitor aiming at various different monitoring data and is used for recording real network state monitoring data. The operation flow of the network state monitor is shown in fig. 2, the network state monitor firstly processes and analyzes data by using a statistical method to obtain a statistical value of the change of the network state monitoring data, when the statistical value of the change of the network state monitoring data exceeds a preset threshold value, a conclusion that the network state is changed is output, at the moment, the current network state is updated, and an estimated bandwidth under the current network state is output; when the statistic value of the change of the network state monitoring data does not exceed a preset threshold value, outputting the conclusion that the network state does not change, and then outputting the estimated bandwidth of the last network state; particularly, the network state monitor can forcibly refresh the network state at regular intervals, so that the network bandwidth allocation strategy provided by the invention can be more fully adapted to the most real network state.
The bandwidth allocation decision maker can inquire the latest network state from the network state monitor at regular time, and when the network state changes, a new round of decision is started. And according to the importance degree of different media sources in the conference, the bandwidth allocation decision maker sequentially allocates the estimated bandwidth in the current network state to audio, screen sharing and video.
As shown in fig. 3, the specific steps of the bandwidth allocation decider generating a new decision in this embodiment are:
step 1-1, determining an audio sending strategy according to current network state monitoring data to obtain bandwidth required by audio;
the audio sending strategy determination method comprises the following specific steps:
step 1-1a, determining the quantity of forward error correction coding redundancy (namely FEC redundancy) and active retransmission packets (namely RED) of pre-allocated audio according to the packet loss rate of the current network;
the specific method for determining the forward error correction coding redundancy and the number of active retransmission packets of the pre-allocated audio comprises the following steps:
judging whether the packet loss rate of the current network is greater than a first threshold value, if so, opening forward error correction coding of the pre-allocated audio, and setting the redundancy of the forward error correction coding of the pre-allocated audio as 100%; if not, not opening the forward error correction coding, and setting the forward error correction coding redundancy of the pre-allocated audio to be 0; in the embodiment, the value of the first threshold is 3-6%;
in addition, whether the packet loss rate of the current network is greater than a second threshold value is judged, if yes, active retransmission of pre-allocated audio is started, and the rule that the packet loss rate is gradually increased and the number of active retransmission packets is gradually increased is followed, so that the number of active retransmission packets is determined according to the packet loss rate of the current network; if not, not opening the active retransmission, wherein the number of the active retransmission packets is 0; the value of the second threshold value in the embodiment is 10-20%;
step 1-1b, calculating bandwidth Br required by pre-distributing audio1;
Br1=codec1*(1+K1)*(1+RED1)
Wherein, codec1Representing the coding rate, K, of the audio coding1The amount of forward error correction coding redundancy for pre-allocated audio, depending on whether forward error correction coding is turned on, K1=100% or 0; RED1Representing the number of active retransmission packets of pre-allocated audio;
step 1-1c, judging whether the estimated bandwidth in the current network state is enough to pre-allocate the forward of the audioBandwidth Br required for error correction coding redundancy and number of active retransmission packets1If yes, pre-allocating the bandwidth Br required by the audio1As the current audio sending strategy, and the step 1-1d is carried out; if not, gradually reducing the number of active retransmission packets of the pre-allocated audio, and recalculating the bandwidth Br required by the pre-allocated audio according to the formula in the step 1-1b1Making newly calculated bandwidth Br required for pre-allocation of audio estimates1Less than the estimated bandwidth in the current network state, and then estimating the newly calculated bandwidth Br required for pre-allocation of audio1As the current audio sending strategy, and the step 1-1d is carried out;
step 1-1d, outputting the bandwidth required by the audio;
step 1-2, combining previous network state monitoring data and the round-trip delay condition in the current network state to determine whether to start passive packet loss retransmission;
the method for confirming whether the passive packet loss retransmission is started or not comprises the following steps: the previous network state monitoring data can influence the round-trip delay time in the current network state, so that whether the round-trip delay time in the current network state is greater than a preset time threshold value or not is judged, if yes, passive packet loss retransmission is not started, and if not, passive packet loss retransmission is started;
if the passive packet loss retransmission is not started, setting the passive packet loss retransmission coefficient in the current network state as 1;
if the passive packet loss retransmission is started, setting a passive packet loss retransmission coefficient in the current network state as NackCoefficient (sendTimes);
the calculation formula of NackCoefficient (sendTimes) is as follows:
NackCoefficient(sendTimes)=1+losssendTimes
wherein loss represents packet loss rate, and sendcopies represents the retransmission times of passive packet loss;
step 1-3, determining a screen sharing strategy according to the current network state monitoring data and the starting state of the passive packet loss retransmission, and obtaining the bandwidth required by screen sharing and the passive packet loss retransmission bandwidth required by screen sharing;
the specific steps of determining the screen sharing strategy are as follows:
step 1-3a, determining the shared forward error correction coding redundancy and the number of active retransmission packets of a pre-allocated screen according to the packet loss rate and the passive packet loss retransmission state in the current network state;
the specific method for determining the forward error correction coding redundancy quantity and the number of the active retransmission packets shared by the pre-allocated screen comprises the following steps:
in order to prevent accidental network jitter, the lowest value of forward error correction coding redundancy shared by the pre-allocated screens is set as Lmin; in this example, lmin =10%; and following the rule that when the packet loss rate is gradually increased, the forward error correction coding redundancy shared by the pre-allocated screens is also gradually increased (different packet loss rates and corresponding forward error correction coding redundancy shared by the pre-allocated screens can be written in a table), determining the forward error correction coding redundancy shared by the pre-allocated screens according to the packet loss rate of the current network, wherein the highest value of the forward error correction coding redundancy shared by the pre-allocated screens is 100%;
if the packet loss rate of the current network is greater than a third threshold value, opening active retransmission shared by the pre-allocated screens, and following the rule that the packet loss rate is gradually increased and the number of the active retransmission packets shared by the pre-allocated screens is gradually increased, so that the number of the active retransmission packets shared by the pre-allocated screens is determined according to the packet loss rate of the current network; if not, not opening the active retransmission shared by the pre-allocation screen, wherein the number of the active retransmission packets shared by the pre-allocation screen is 0; in this embodiment, the third threshold is 20%;
step 1-3b, calculating bandwidth Br required by sharing pre-allocated screen2(ii) a The calculation formula is as follows:
Br2=codec2*NackCoefficient(1+RED2)*(1+K2)*(1+RED2)
in the formula: codec2Representing screen-shared coding rate, codec2Positively correlated with the transmission time level tLevel shared by the screens sharing the coding rate codec2The method has an initial preset value, namely the sending time level tLevel shared by the screens has an initial value, and the value range of tLevel is generallyThe circumference is 0 to 15, and the initial value is 15; RED2Indicates the number of active retransmission packets shared by the pre-allocated screen, nackCoefficient (1 + RED)2) For passive packet loss retransmission coefficient, when passive packet loss retransmission state is not started, nackCoefficient (1 +RED)2) =1, when the passive packet loss retransmission state is started, 1+ RED2Substituting the sendTimes as the packet loss retransmission times into a calculation formula of a passive packet loss retransmission coefficient; k is2Representing the amount of forward error correction coding redundancy of the pre-allocated screen share;
step 1-3c, subtracting the bandwidth required by the audio from the estimated bandwidth in the current network state to obtain a first remaining available bandwidth, and judging whether the first remaining available bandwidth is enough to pre-allocate the bandwidth Br required by the screen sharing2If yes, the bandwidth Br required by pre-allocation screen sharing is satisfied2As the current screen sharing sending strategy, and the step 1-3e is carried out; if not, turning to the step 1-3d;
step 1-3d, adjusting the bandwidth required by the sharing of the pre-allocated screen in sequence according to the following steps:
1-3d (1), reducing the screen sharing coding rate;
when the coding code rate of the screen sharing is gradually reduced, recalculating the bandwidth Br required by the pre-allocated screen sharing according to the formula of the step 1-3b2To make the pre-allocated screen share the required bandwidth Br2If the bandwidth is less than the first residual available bandwidth, sharing the bandwidth Br required by the recalculated pre-allocated screen2As the current screen sharing sending strategy, and the step 1-3e is carried out; if the coding code rate of the screen sharing is reduced to the minimum value, the bandwidth Br required by the pre-distributed screen sharing is obtained through recalculation2If the first remaining available bandwidth is still larger than or equal to the first remaining available bandwidth, the step 1-3d (2) is carried out;
step 1-3d (2), reducing the number of active retransmission packets shared by the screen, and resetting the coding rate shared by the screen to an initial value;
after the number of active retransmission packets shared by the screen is reduced each time, the coding code rate shared by the screen is gradually reduced, and then the pre-distributed screen sharing is recalculated according to the formula of the step 1-3bRequired bandwidth of Br2Until the recalculated pre-allocated screen shares the required bandwidth of Br2If the bandwidth is less than the first residual available bandwidth, the recalculated pre-allocated screen is shared with the required bandwidth Br2As the current screen sharing sending strategy, and the step 1-3e is carried out; if not, turning to the step 1-3d (3);
step 1-3d (3), reducing the forward error correction coding redundancy shared by the pre-allocated screen, and resetting the coding code rate shared by the screen to the initial value;
after the forward error correction coding redundancy amount shared by the pre-allocated screen is reduced each time, the coding code rate shared by the screen is gradually reduced, the number of active retransmission packets shared by the screen is the minimum value, and then the bandwidth Br required by the pre-allocated screen sharing is recalculated according to the formula of the step 1-3b2Until the recalculated pre-allocated screen shares the required bandwidth of Br2If the bandwidth is less than the first residual available bandwidth, the recalculated pre-allocated screen is shared with the required bandwidth Br2As the current screen sharing sending strategy, and turning to the step 1-3e; if the forward error correction coding redundancy shared by the pre-distributed screens is reduced to the minimum value and the coding code rate shared by the screens is reduced to the minimum value, the bandwidth Br required by the pre-distributed screens after recalculation2If the bandwidth is still larger than or equal to the first residual available bandwidth, the bandwidth Br required by the pre-allocated screen sharing obtained by the last sequential calculation is used2As the current screen sharing sending strategy, and turning to the step 1-3e;
step 1-3e, outputting bandwidth required by screen sharing and passive packet loss retransmission bandwidth required by screen sharing;
the bandwidth required by screen sharing is the screen sharing coding code rate, the front and back error correction coding redundancy of pre-distribution screen sharing and the number of active retransmission packets in the current screen sharing transmission strategy are substituted into Br2Obtained by calculation in a formula;
passive packet loss retransmission bandwidth Br required by screen sharingnack1The calculation formula is as follows:
Brnack1=codec2*(NackCoefficient(1+RED2)-1);
the passive packet loss retransmission bandwidth required by the screen sharing in the step is the screen sharing coding code rate and the active retransmission packet quantity in the current screen sharing sending strategy and substituted into Brnack1Obtained by calculation in a formula;
step 1-4, determining a video sending strategy according to the current network state monitoring data and the starting state of the passive packet loss retransmission, and obtaining the bandwidth required by the video and the passive packet loss retransmission bandwidth required by the video;
the specific steps for determining the video sending strategy are as follows:
step 1-4a, determining the forward error correction coding redundancy and the number of active retransmission packets of the pre-distributed video according to the packet loss rate and the passive packet loss retransmission state of the current network;
the specific method for determining the forward error correction coding redundancy quantity and the number of the active retransmission packets of the pre-allocated video comprises the following steps:
in order to prevent accidental network jitter, the lowest value of the forward error correction coding redundancy of the pre-allocated video is set to be L1; in this example, this L1=10%; and following the rule that when the packet loss rate is gradually increased, the forward error correction coding redundancy of the pre-distributed video is also gradually increased (different packet loss rates and corresponding forward error correction coding redundancy of the pre-distributed video can be written in a table), determining the forward error correction coding redundancy of the pre-distributed video according to the packet loss rate of the current network, wherein the highest value of the forward error correction coding redundancy of the pre-distributed video is 100%;
if the packet loss rate of the current network is greater than a fourth threshold value, starting active retransmission of the pre-distributed video, and following the rule that the packet loss rate is gradually increased and the number of active retransmission packets of the pre-distributed video is gradually increased, so that the number of the active retransmission packets of the pre-distributed video is determined according to the packet loss rate of the current network; if not, not opening the active retransmission of the pre-distributed video, wherein the number of the active retransmission packets is 0; in this embodiment, the fourth threshold is 20%;
step 1-4b, calculating bandwidth Br required by pre-distributed video3(ii) a The calculation formula is as follows:
Br3=codec3*NackCoefficient(1+RED3)*(1+K3)*(1+RED3)
in the formula: codec3Representing the coding rate, codec, of the video3Related to a transmission spatial hierarchy of the video and a transmission temporal hierarchy of the video; codec3Having an initial value of codec3The specific value of (a) is related to the encoder configuration; RED3The active retransmission packet number of the pre-allocated video is represented, nackCoefficient (1 + RED 3) is a passive packet loss retransmission coefficient, and when the passive packet loss retransmission state is not started, nackCoefficient (1 + RED 3) =1; when the passive packet loss retransmission state is started, substituting 1+ RED3 as the active packet loss retransmission times sendTimes into a calculation formula of the passive packet loss retransmission coefficient; k3Representing the amount of forward error correction coding redundancy of the pre-allocated video;
1-4c, subtracting the bandwidth required by screen sharing from the first residual available bandwidth to obtain a second residual available bandwidth; and determines whether the second remaining available bandwidth is sufficient to pre-allocate the bandwidth Br required by the video3If yes, the bandwidth Br required by the pre-distributed video is satisfied3As the current video sending strategy, the method is shifted to the step 1-4e; if not, turning to the step 1-4d;
step 1-4d, adjusting the bandwidth required by the pre-distributed video in sequence according to the following steps:
1-4d (1), reducing the coding rate of the video;
if the coding code rate of the video is gradually reduced, recalculating the bandwidth Br required by the pre-distributed video according to the formula of the step 1-4b3To make the bandwidth Br required for pre-distributing video3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the encoding code rate of the video is reduced to the minimum value, the bandwidth Br required by the pre-distributed video after recalculation3If the bandwidth is still larger than or equal to the second remaining available bandwidth, the step 1-4d (2) is carried out;
step 1-4d (2), reducing the number of active retransmission packets of the video, and resetting the coding code rate of the video to an initial value;
after the number of active retransmission packets of the video is reduced each time, the coding code rate of the video is adjusted, and then the bandwidth Br required by the pre-distributed video is recalculated according to the formula of the step 1-4b3Until the bandwidth Br required by the recalculated pre-allocated video3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the number of the active retransmission packets of the video is reduced to the minimum value and the coding code rate of the video is reduced to the minimum value at the same time, the bandwidth Br required by the pre-distributed video after recalculation is carried out3If the bandwidth is still larger than or equal to the second residual available bandwidth, the step 1-4d (4) is carried out;
step 1-4d (4), reducing the redundancy of forward error correction coding of the pre-distributed video, and resetting the coding rate of the video to an initial value;
after the forward error correction coding redundancy of the pre-distributed video is reduced each time, the coding rate of the video is adjusted, and then the bandwidth Br required by the pre-distributed video is recalculated according to the formula of the step 1-4b3Until the bandwidth Br required for pre-distributing the video is recalculated3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the redundancy of the forward error correction coding of the pre-distributed video is reduced to the minimum value and the coding code rate of the video is reduced to the minimum value, recalculating the bandwidth Br required by the pre-distributed video3If the bandwidth is still larger than or equal to the second residual available bandwidth, the bandwidth Br required by the pre-distributed video obtained by the final sequential calculation is used3As the current video sending strategy, and the step 1-4e is carried out;
step 1-4e, outputting bandwidth required by the video and passive packet loss retransmission bandwidth required by the video;
the bandwidth required by the video is the code rate in the current video transmission strategy, the front and back error correction coding redundancy of the pre-distributed video and the number of active retransmission packets are substituted into Br3Obtained by calculation in a formula;
passive packet loss retransmission bandwidth required for videoBrnack2The calculation formula is as follows:
Brnack2=codec3*(NackCoefficient(1+RED3)-1);
the passive packet loss retransmission bandwidth required by the video in the step is the video coding code rate and the number of active retransmission packets in the current video transmission strategy, and the bandwidth is substituted into Brnack2Obtained by calculation in a formula;
step 1-5, confirming the maximum bandwidth available for passive packet loss retransmission; the method specifically comprises the following steps:
subtracting the bandwidth required by audio, the bandwidth required by screen sharing and the bandwidth required by video from the estimated bandwidth in the current network state to obtain the residual bandwidth;
judging whether the residual bandwidth is larger than the sum of the passive packet loss retransmission bandwidth required by screen sharing and the passive packet loss retransmission bandwidth required by the video, if so, taking the residual bandwidth as the maximum bandwidth available for the final passive packet loss retransmission; if not, taking the result of the residual bandwidth x k as the maximum bandwidth available for the final passive packet loss retransmission, wherein k is a preset coefficient; the value range of k is: k is more than 1.05 and less than 1.2; preferred k =1.1 in the present embodiment;
step 1-6, taking the bandwidth required by the audio, the bandwidth required by screen sharing, the passive packet loss retransmission bandwidth required by screen sharing, the bandwidth required by video, the passive packet loss retransmission bandwidth required by video and the maximum bandwidth available for passive packet loss retransmission as a new bandwidth allocation decision;
step 1-7, inquiring the opinion of the decision result monitor, if the decision result monitor feeds back that the call quality Q1 corresponding to the new bandwidth allocation strategy S1 is superior to the call quality Q0 corresponding to the last bandwidth allocation strategy S0, the bandwidth allocation decision maker executes the new decision according to the bandwidth allocation in the step 1-6 through the sending end; and when the decision result monitor feeds back that the call quality Q1 corresponding to the new bandwidth allocation strategy S1 is inferior to the call quality Q0 corresponding to the last bandwidth allocation strategy S0, the bandwidth allocation decision maker informs the sending end to execute according to the last bandwidth allocation strategy.
The decision result monitor is used for monitoring the call quality after a new bandwidth allocation strategy output by the bandwidth allocation decision device takes effect and executes for a certain time, then comparing the call quality with the call quality according to the last bandwidth allocation strategy, and feeding back the comparison result of the new call quality and the last call quality to the bandwidth allocation decision device.
The working process of the decision result monitor in the embodiment specifically comprises the following steps:
step 2-1, recording a new bandwidth allocation strategy S1 and call quality Q1 corresponding to the new bandwidth allocation strategy S1, and recording a last bandwidth allocation strategy S0 of the new bandwidth allocation strategy S1 and call quality Q0 corresponding to the last bandwidth allocation strategy S0;
step 2-2, comparing the call quality Q0 corresponding to the last bandwidth allocation strategy S0 with the call quality Q1 corresponding to the new bandwidth allocation strategy S1, and judging whether the Q1 is inferior to the Q0, if so, outputting the call quality Q1 corresponding to the new bandwidth allocation strategy S1 to be inferior to the call quality Q0 corresponding to the last bandwidth allocation strategy S0; if not, the call quality Q1 corresponding to the new bandwidth allocation strategy S1 is output to be superior to the call quality Q0 corresponding to the last bandwidth allocation strategy S0.
Compared with the old technical scheme, the definition and the fluency of the video are improved after the new solution is applied.
1. When the network state is not changed, the selection of the sending resolution is more stable than before, so that the picture fluctuation caused by the change of the resolution is reduced, and the user experience is better; tests show that the new decision scheme improves the stability of the resolution by 50 percent compared with the original resolution.
2. When the network state changes or the subscription state changes, the new decision-making system reacts more sensitively and can reach a new stable point more quickly. For example, in a scene where 80% of packet loss occurs suddenly in the network, after the new decision scheme is applied, the estimation of the available bandwidth of the conference can be recovered more quickly, so that the picture pause time is reduced by more than 20%.
Claims (10)
1. A bandwidth resource allocation system of an RTC system, comprising: a network state monitor, a bandwidth allocation decision maker and a decision result monitor;
the network state monitor is used for receiving the network state monitoring data in real time, analyzing the network state monitoring data to obtain the current network state and outputting the estimated bandwidth in the current network state;
the bandwidth allocation decision maker requests the network state monitor to inquire the current network state at regular time, acquires the estimated bandwidth in the current network state, generates an initial bandwidth allocation decision according to the estimated bandwidth in the current network state and outputs the initial bandwidth allocation decision to the sending end, and after the sending end operates for a period of time according to the initial bandwidth allocation decision, synthesizes the current network state and the result fed back by the decision result monitor to generate a new bandwidth allocation decision and outputs the new bandwidth allocation decision to the sending end so that the sending end operates according to the new bandwidth allocation strategy;
and the decision result monitor is used for acquiring the initial call quality after the sending end operates for a period of time according to the initial bandwidth allocation decision, acquiring the new call quality after the sending end operates for a period of time according to the new bandwidth allocation strategy, comparing the new call quality with the initial call quality and feeding the comparison result of the new call quality and the initial call quality back to the bandwidth allocation decision maker.
2. The bandwidth resource allocation system of the RTC system of claim 1, wherein: and the bandwidth allocation decision maker sequentially allocates the estimated bandwidth in the current network state to the audio, the screen sharing and the video according to the sequence.
3. The bandwidth resource allocation system of the RTC system of claim 2, wherein: the specific steps of the bandwidth allocation decision maker for generating a new decision are as follows:
step 1-1, determining an audio sending strategy according to current network state monitoring data to obtain bandwidth required by audio;
step 1-2, determining whether to start passive packet loss retransmission or not by combining previous network state monitoring data and the round-trip delay condition in the current network state;
step 1-3, determining a screen sharing strategy according to the current network state monitoring data and the starting state of the passive packet loss retransmission, and obtaining the bandwidth required by screen sharing and the passive packet loss retransmission bandwidth required by screen sharing;
step 1-4, determining a video sending strategy according to the current network state monitoring data and the starting state of the passive packet loss retransmission, and obtaining the bandwidth required by the video and the passive packet loss retransmission bandwidth required by the video;
step 1-5, confirming the maximum bandwidth available for passive packet loss retransmission; the method specifically comprises the following steps:
subtracting the bandwidth required by audio, the bandwidth required by screen sharing and the bandwidth required by video from the estimated bandwidth in the current network state to obtain the residual bandwidth;
judging whether the residual bandwidth is larger than the sum of the passive packet loss retransmission bandwidth required by screen sharing and the passive packet loss retransmission bandwidth required by the video, if so, taking the residual bandwidth as the maximum available bandwidth for the final passive packet loss retransmission; if not, taking the result of the residual bandwidth xk as the maximum available bandwidth for the final passive packet loss retransmission;
step 1-6, taking the bandwidth required by the audio, the bandwidth required by screen sharing, the passive packet loss retransmission bandwidth required by screen sharing, the bandwidth required by the video, the passive packet loss retransmission bandwidth required by the video and the maximum bandwidth available for passive packet loss retransmission as new bandwidth allocation decisions;
step 1-7, inquiring the opinion of the decision result monitor, if the call quality corresponding to the new bandwidth allocation strategy fed back by the decision result monitor is superior to the call quality corresponding to the last bandwidth allocation strategy, the bandwidth allocation decision-making device executes the new decision according to the bandwidth allocation in step 1-6 by the sending end; and when the call quality corresponding to the new bandwidth allocation strategy is lower than the call quality corresponding to the last bandwidth allocation strategy fed back by the decision result monitor, the bandwidth allocation decision-making device informs the sending end to execute according to the last bandwidth allocation strategy.
4. The bandwidth resource allocation system of the RTC system of claim 3, wherein: the specific steps of determining the audio sending strategy in the step 1-1 are as follows:
step 1-1a, determining the forward error correction coding redundancy of pre-allocated audio and the number of active retransmission packets according to the packet loss rate of the current network;
step 1-1b, calculating bandwidth Br required by pre-distributing audio1;
Br1=codec1*(1+K1)*(1+RED1)
Wherein, codec1Representing the code rate, K, of the audio coding1The amount of forward error correction coding redundancy for pre-allocated audio, depending on whether forward error correction coding is turned on, K1=100% or 0; RED1Representing the number of active retransmission packets of pre-allocated audio;
step 1-1c, judging whether the estimated bandwidth in the current network state is enough to pre-allocate the forward error correction coding redundancy of the audio and the bandwidth Br required by the number of the active retransmission packets1If yes, pre-distributing the bandwidth Br required by the audio1As the current audio sending strategy, and the step 1-1d is carried out; if not, the number of active retransmission packets of the pre-distributed audio is gradually reduced, and the bandwidth Br required by the pre-distributed audio is recalculated according to the formula in the step 1-1b1Bandwidth Br required to make the newly calculated pre-assigned audio estimate1Less than the estimated bandwidth in the current network state, and then calculating the bandwidth Br required by the pre-distributed audio estimation1As the current audio sending strategy, and the step 1-1d is carried out;
and 1-1d, outputting the bandwidth required by the audio.
5. The bandwidth resource allocation system of the RTC system of claim 4, wherein: the specific method for determining the forward error correction coding redundancy and the number of active retransmission packets of the pre-allocated audio in the step 1-1a is as follows:
judging whether the packet loss rate of the current network is greater than a first threshold value, if so, opening forward error correction coding of the pre-allocated audio, and setting the redundancy of the forward error correction coding of the pre-allocated audio as 100%; if not, not opening the forward error correction coding, and setting the forward error correction coding redundancy of the pre-allocated audio to be 0;
in addition, whether the packet loss rate of the current network is greater than a second threshold value is judged, if yes, active retransmission of pre-allocated audio is started, and the rule that the packet loss rate is gradually increased and the number of active retransmission packets is gradually increased is followed, so that the number of active retransmission packets is determined according to the packet loss rate of the current network; if not, the active retransmission is not opened, and the number of the active retransmission packets is 0.
6. A bandwidth resource allocation system of an RTC system according to claim 3, characterized by: the method for confirming whether the passive packet loss retransmission is started in the step 1-2 comprises the following steps:
judging whether the round-trip delay time in the current network state is greater than a preset time threshold, if so, not starting passive packet loss retransmission, and if not, starting passive packet loss retransmission;
if the passive packet loss retransmission is not started, setting a passive packet loss retransmission coefficient in the current network state as 1;
if the passive packet loss retransmission is started, setting a passive packet loss retransmission coefficient in the current network state as NackCoefficient (sendTimes);
the calculation formula of NackCoefficient (sendTimes) is as follows:
NackCoefficient(sendTimes)=1+losssendTimes
wherein loss represents the packet loss rate, and sendTimes represents the number of passive packet loss retransmission.
7. The bandwidth resource allocation system of the RTC system of claim 6, wherein: the specific steps of determining the screen sharing strategy in the step 1-3 are as follows:
step 1-3a, determining the shared forward error correction coding redundancy and the number of active retransmission packets of a pre-allocated screen according to the packet loss rate and the passive packet loss retransmission state in the current network state;
step 1-3b, calculating bandwidth Br required by sharing pre-allocated screen2(ii) a The calculation formula is as follows:
Br2=codec2*NackCoefficient(1+RED2)*(1+K2)*(1+RED2)
in the formula: codec2Representing screen-shared code rate codec2Having an initial preset value, RED2Indicates the number of active retransmission packets shared by the pre-allocated screen, nackCoefficient (1 + RED)2) For passive packet loss retransmission coefficient, when the passive packet loss retransmission state is not started, nackCoefficient (1 ++ RED)2) =1, when passive packet loss retransmission state is started, 1+ RED2Substituting the sendTimes as the packet loss retransmission times into a calculation formula of a passive packet loss retransmission coefficient; k is2Representing the amount of forward error correction coding redundancy of the pre-allocated screen share;
step 1-3c, subtracting the bandwidth required by the audio from the estimated bandwidth in the current network state to obtain a first remaining available bandwidth, and judging whether the first remaining available bandwidth is enough to pre-allocate the bandwidth Br required by the screen sharing2If yes, the bandwidth Br required by pre-allocation screen sharing is met2As the current screen sharing sending strategy, and turning to the step 1-3e; if not, turning to the step 1-3d;
step 1-3d, adjusting the bandwidth required by the sharing of the pre-allocated screen in sequence according to the following steps:
1-3d (1), reducing the screen sharing code rate;
when the coding code rate of the screen sharing is gradually reduced, recalculating the bandwidth Br required by the pre-allocated screen sharing according to the formula of the step 1-3b2To make the pre-allocated screen share the required bandwidth Br2If the bandwidth is less than the first residual available bandwidth, the recalculated pre-allocated screen is shared with the required bandwidth Br2As the current screen sharing sending strategy, and turning to the step 1-3e; if the coding code rate of the screen sharing is reduced to the minimum value, the bandwidth Br required by the pre-distributed screen sharing is obtained through recalculation2If the first remaining available bandwidth is still larger than or equal to the first remaining available bandwidth, the step 1-3d (2) is carried out;
step 1-3d (2), reducing the number of active retransmission packets shared by the screen, and resetting the coding rate shared by the screen to an initial value;
each time decreasingAfter the number of active retransmission packets shared by a few screens is reduced, the coding code rate shared by the screens is gradually reduced, and then the bandwidth Br required by the pre-distribution screen sharing is recalculated according to the formula of the step 1-3b2Until the recalculated pre-allocated screen shares the required bandwidth of Br2If the bandwidth is less than the first residual available bandwidth, the recalculated pre-allocated screen is shared with the required bandwidth Br2As the current screen sharing sending strategy, and turning to the step 1-3e; if not, turning to the step 1-3d (3);
step 1-3d (3), reducing the forward error correction coding redundancy shared by the pre-allocated screen, and resetting the coding code rate shared by the screen to the initial value;
after the forward error correction coding redundancy amount shared by the pre-allocated screen is reduced each time, the coding code rate shared by the screen is gradually reduced, the number of active retransmission packets shared by the screen is the minimum value, and then the bandwidth Br required by the pre-allocated screen sharing is recalculated according to the formula of the step 1-3b2Until the recalculated pre-allocated screen shares the required bandwidth of Br2If the bandwidth is less than the first residual available bandwidth, the recalculated pre-allocated screen is shared with the required bandwidth Br2As the current screen sharing sending strategy, and turning to the step 1-3e; if the forward error correction coding redundancy shared by the pre-distributed screens is reduced to the minimum value and the coding code rate shared by the screens is reduced to the minimum value, the bandwidth Br required by the pre-distributed screens after recalculation2If the bandwidth is still larger than or equal to the first residual available bandwidth, the bandwidth Br required by the pre-allocated screen sharing obtained by the last sequential calculation is used2As the current screen sharing sending strategy, and the step 1-3e is carried out;
step 1-3e, outputting bandwidth required by screen sharing and passive packet loss retransmission bandwidth required by screen sharing;
the bandwidth required by screen sharing is the screen sharing coding code rate, the front and back error correction coding redundancy of pre-distribution screen sharing and the number of active retransmission packets in the current screen sharing transmission strategy are substituted into Br2Obtained by calculation in a formula;
passive packet loss retransmission bandwidth Br required by screen sharingnack1The calculation formula is as follows:
Brnack1=codec2*(NackCoefficient(1+RED2)-1);
the passive packet loss retransmission bandwidth required by the screen sharing in the step is the screen sharing coding code rate and the active retransmission packet quantity in the current screen sharing sending strategy and substituted into Brnack1And calculating the formula.
8. The bandwidth resource allocation system of the RTC system of claim 7, wherein: the specific method for determining the forward error correction coding redundancy and the number of the active retransmission packets shared by the pre-allocated screens in the step 1-3a is as follows:
setting the lowest value of the forward error correction coding redundancy shared by the pre-allocated screens as Lmin, and setting the highest value of the forward error correction coding redundancy shared by the pre-allocated screens as 100%; determining the forward error correction coding redundancy shared by the pre-allocated screen according to the packet loss rate of the current network according to the rule that the forward error correction coding redundancy shared by the pre-allocated screen is gradually increased when the packet loss rate is gradually increased;
if the packet loss rate of the current network is greater than a third threshold value, opening active retransmission shared by the pre-allocated screens, and following the rule that the packet loss rate is gradually increased and the number of the active retransmission packets shared by the pre-allocated screens is gradually increased, so that the number of the active retransmission packets shared by the pre-allocated screens is determined according to the packet loss rate of the current network; if not, not opening the active retransmission shared by the pre-allocation screen, and the number of the active retransmission packets shared by the pre-allocation screen is 0.
9. A bandwidth resource allocation system of the RTC system of claim 6, characterized in that: the video sending strategy determination in the steps 1-4 comprises the following specific steps:
step 1-4a, determining the forward error correction coding redundancy and the number of active retransmission packets of the pre-distributed video according to the packet loss rate and the passive packet loss retransmission state of the current network;
step 1-4b, calculating bandwidth Br required by pre-distribution video3(ii) a The calculation formula is as follows:
Br3=codec3*NackCoefficient(1+RED3)*(1+K3)*(1+RED3)
in the formula: codec3Code rate, codec, representing video3Has an initial value; RED3The active retransmission packet number of the pre-allocated video is represented, nackCoefficient (1 + RED 3) is a passive packet loss retransmission coefficient, and when the passive packet loss retransmission state is not started, nackCoefficient (1 + RWDD 3) =1; when the passive packet loss retransmission state is started, substituting 1+ RED3 as the active packet loss retransmission times sendTimes into a calculation formula of the passive packet loss retransmission coefficient; k3Representing the amount of forward error correction coding redundancy of the pre-allocated video;
1-4c, subtracting the bandwidth required by screen sharing from the first residual available bandwidth to obtain a second residual available bandwidth; and determines whether the second remaining available bandwidth is sufficient to pre-allocate the bandwidth Br required by the video3If yes, the bandwidth Br required by the pre-distributed video is satisfied3As the current video sending strategy, and the step 1-4e is carried out; if not, turning to the step 1-4d;
step 1-4d, adjusting the bandwidth required by the pre-distributed video in sequence according to the following steps:
1-4d (1), reducing the coding rate of the video;
if the coding code rate of the video is gradually reduced, recalculating the bandwidth Br required by the pre-distributed video according to the formula of the step 1-4b3Bandwidth Br required to pre-allocate video3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the encoding code rate of the video is reduced to the minimum value, the bandwidth Br required by the pre-distributed video after recalculation3If the bandwidth is still larger than or equal to the second remaining available bandwidth, the step 1-4d (2) is carried out;
step 1-4d (2), reducing the number of active retransmission packets of the video, and resetting the coding code rate of the video to an initial value;
after the number of active retransmission packets of the video is reduced each time, the video is editedAdjusting code rate, and recalculating the bandwidth Br required by the pre-distributed video according to the formula of the step 1-4b3Until the bandwidth Br required by the recalculated pre-distributed video3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the number of the active retransmission packets of the video is reduced to the minimum value and the coding code rate of the video is reduced to the minimum value, the bandwidth Br required by the pre-distributed video after recalculation is carried out3If the bandwidth is still larger than or equal to the second remaining available bandwidth, the step 1-4d (4) is carried out;
1-4d (4), reducing the forward error correction coding redundancy of the pre-distributed video, and resetting the coding code rate of the video to an initial value;
after the forward error correction coding redundancy of the pre-distributed video is reduced each time, the coding rate of the video is adjusted, and then the bandwidth Br required by the pre-distributed video is recalculated according to the formula of the step 1-4b3Until the bandwidth Br required for pre-distributing the video is recalculated3If the bandwidth is less than the second residual available bandwidth, the bandwidth Br required by the recalculated pre-distributed video is determined3As the current video sending strategy, and the step 1-4e is carried out; if the redundancy of the forward error correction coding of the pre-distributed video is reduced to the minimum value and the coding code rate of the video is reduced to the minimum value, recalculating the bandwidth Br required by the pre-distributed video3If the bandwidth is still larger than or equal to the second residual available bandwidth, the bandwidth Br required by the pre-distributed video obtained by the final sequential calculation is used3As the current video sending strategy, and the step 1-4e is carried out;
step 1-4e, bandwidth required by video output and passive packet loss retransmission bandwidth required by video output;
the bandwidth required by the video is the code rate in the current video transmission strategy, the front and back error correction coding redundancy of the pre-distributed video and the number of active retransmission packets are substituted into Br3Obtained by calculation in a formula;
passive packet loss retransmission bandwidth Br required by videonack2The calculation formula is as follows:
Brnack2=codec3*(NackCoefficient(1+RED3)-1);
the passive packet loss retransmission bandwidth required by the video in the step is the video coding code rate and the number of active retransmission packets in the current video transmission strategy, and the bandwidth is substituted into Brnack2And calculating the formula.
10. The bandwidth resource allocation system of the RTC system according to any one of claims 1 to 9, wherein: the working process of the decision result monitor comprises the following specific steps:
step 2-1, recording a new bandwidth allocation strategy (S1) and call quality (Q1) corresponding to the new bandwidth allocation strategy (S1), and recording a last bandwidth allocation strategy (S0) of the new bandwidth allocation strategy (S1) and call quality (Q0) corresponding to the last bandwidth allocation strategy (S0);
step 2-2, comparing the call quality (Q0) corresponding to the last bandwidth allocation strategy (S0) with the call quality (Q1) corresponding to the new bandwidth allocation strategy (S1), and judging whether the call quality (Q1) is inferior to the call quality (Q0), if so, outputting the call quality (Q1) corresponding to the new bandwidth allocation strategy (S1) to be inferior to the call quality (Q0) corresponding to the last bandwidth allocation strategy (S0); if not, the call quality (Q1) corresponding to the new bandwidth allocation strategy (S1) is output to be superior to the call quality (Q0) corresponding to the last bandwidth allocation strategy (S0).
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210855229.8A CN115277654B (en) | 2022-07-19 | 2022-07-19 | Bandwidth resource allocation system of RTC system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210855229.8A CN115277654B (en) | 2022-07-19 | 2022-07-19 | Bandwidth resource allocation system of RTC system |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115277654A true CN115277654A (en) | 2022-11-01 |
CN115277654B CN115277654B (en) | 2024-02-27 |
Family
ID=83768328
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210855229.8A Active CN115277654B (en) | 2022-07-19 | 2022-07-19 | Bandwidth resource allocation system of RTC system |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115277654B (en) |
Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6208640B1 (en) * | 1998-02-27 | 2001-03-27 | David Spell | Predictive bandwidth allocation method and apparatus |
US20040148423A1 (en) * | 2003-01-27 | 2004-07-29 | Key Peter B. | Reactive bandwidth control for streaming data |
US20090164657A1 (en) * | 2007-12-20 | 2009-06-25 | Microsoft Corporation | Application aware rate control |
US20110153863A1 (en) * | 2009-12-21 | 2011-06-23 | Microsoft Corporation | Distributing bandwidth across communication modalities |
US20130215774A1 (en) * | 2004-03-11 | 2013-08-22 | Augme Technologies, Inc. | System and method of media over an internet protocol communication |
US20130297819A1 (en) * | 2012-05-01 | 2013-11-07 | Citrix Online Llc | Method and Apparatus for Bandwidth Allocation and Estimation |
CN103560978A (en) * | 2013-10-14 | 2014-02-05 | 北京邮电大学 | Method and device for bandwidth dynamic allocation in optical access network |
CN103957222A (en) * | 2014-05-20 | 2014-07-30 | 艾诺通信系统(苏州)有限责任公司 | Video transmission self-adaption method based on FEC algorithm |
EP2852176A1 (en) * | 2012-06-18 | 2015-03-25 | ZTE Corporation | Dynamic bandwidth allocation method, device and system |
US9083770B1 (en) * | 2013-11-26 | 2015-07-14 | Snapchat, Inc. | Method and system for integrating real time communication features in applications |
CN105610635A (en) * | 2016-02-29 | 2016-05-25 | 腾讯科技(深圳)有限公司 | Voice code transmitting method and apparatus |
CN112291498A (en) * | 2020-10-30 | 2021-01-29 | 新东方教育科技集团有限公司 | Audio and video data transmission method and device and storage medium |
CN113573003A (en) * | 2021-08-11 | 2021-10-29 | 睿云联(厦门)网络通讯技术有限公司 | Weak network-based audio and video real-time communication method, device and equipment |
CN114666225A (en) * | 2022-03-10 | 2022-06-24 | 阿里巴巴(中国)有限公司 | Bandwidth adjustment method, data transmission method, device and computer storage medium |
-
2022
- 2022-07-19 CN CN202210855229.8A patent/CN115277654B/en active Active
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6208640B1 (en) * | 1998-02-27 | 2001-03-27 | David Spell | Predictive bandwidth allocation method and apparatus |
US20040148423A1 (en) * | 2003-01-27 | 2004-07-29 | Key Peter B. | Reactive bandwidth control for streaming data |
US20130215774A1 (en) * | 2004-03-11 | 2013-08-22 | Augme Technologies, Inc. | System and method of media over an internet protocol communication |
US20090164657A1 (en) * | 2007-12-20 | 2009-06-25 | Microsoft Corporation | Application aware rate control |
US20110153863A1 (en) * | 2009-12-21 | 2011-06-23 | Microsoft Corporation | Distributing bandwidth across communication modalities |
US20130297819A1 (en) * | 2012-05-01 | 2013-11-07 | Citrix Online Llc | Method and Apparatus for Bandwidth Allocation and Estimation |
EP2852176A1 (en) * | 2012-06-18 | 2015-03-25 | ZTE Corporation | Dynamic bandwidth allocation method, device and system |
CN103560978A (en) * | 2013-10-14 | 2014-02-05 | 北京邮电大学 | Method and device for bandwidth dynamic allocation in optical access network |
US9083770B1 (en) * | 2013-11-26 | 2015-07-14 | Snapchat, Inc. | Method and system for integrating real time communication features in applications |
CN103957222A (en) * | 2014-05-20 | 2014-07-30 | 艾诺通信系统(苏州)有限责任公司 | Video transmission self-adaption method based on FEC algorithm |
CN105610635A (en) * | 2016-02-29 | 2016-05-25 | 腾讯科技(深圳)有限公司 | Voice code transmitting method and apparatus |
CN112291498A (en) * | 2020-10-30 | 2021-01-29 | 新东方教育科技集团有限公司 | Audio and video data transmission method and device and storage medium |
CN113573003A (en) * | 2021-08-11 | 2021-10-29 | 睿云联(厦门)网络通讯技术有限公司 | Weak network-based audio and video real-time communication method, device and equipment |
CN114666225A (en) * | 2022-03-10 | 2022-06-24 | 阿里巴巴(中国)有限公司 | Bandwidth adjustment method, data transmission method, device and computer storage medium |
Non-Patent Citations (1)
Title |
---|
丰洪才;向云柱;: "视频传输自适应网络带宽控制策略的研究", 计算机测量与控制, no. 03 * |
Also Published As
Publication number | Publication date |
---|---|
CN115277654B (en) | 2024-02-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11349900B2 (en) | Voice encoding and sending method and apparatus | |
Bolot et al. | Scalable feedback control for multicast video distribution in the internet | |
CN111615006B (en) | Video code conversion transmission control system based on network state self-evaluation | |
RU2497304C2 (en) | Dynamic modification of video properties | |
Bolot et al. | Experience with control mechanisms for packet video in the Internet | |
DE60305793T2 (en) | Method, transmitter and receiver for adapting the coding rate to an alternating transmission rate | |
KR20040041170A (en) | Data communications method and system using receiving buffer size to calculate transmission rate for congestion control | |
Habachi et al. | MOS-based congestion control for conversational services in wireless environments | |
KR100982630B1 (en) | Device and process for adjusting the bit rate of a stream of contents and associated products | |
CN107483990B (en) | Dynamic code rate adjusting method and device for streaming media transmission and transmission system | |
CN111162877A (en) | Adaptive forward error correction method for audio and video service quality control and application | |
CN115277654B (en) | Bandwidth resource allocation system of RTC system | |
CN113747102A (en) | Video call processing method, device, equipment and storage medium | |
CN109587488A (en) | A kind of choosing method for the long reference frame predicted based on rate-distortion optimization and frame losing | |
Kang et al. | Impact of FEC overhead on scalable video streaming | |
Li et al. | A fuzzy-based adaptation controller for low latency live video streaming | |
CN114501014A (en) | Video coding parameter processing method, system, device and storage medium | |
Duffield et al. | Issues of quality and multiplexing when smoothing rate adaptive video | |
Wakamiya et al. | TCP-friendly video transfer | |
CN116634203B (en) | Multi-collaborative self-adaptive video quality optimization method | |
KR100686395B1 (en) | The multi-media streaming method and system of a network adaptation live broadcasting for packet filtering | |
CN117614590A (en) | Method, device and equipment for determining redundancy code rate based on hybrid retransmission | |
Dujfield et al. | Feedback of rate and loss information for networked video | |
Meylan et al. | Realisation of an adaptive audio tool | |
Huang et al. | Hierarchical qoe model for wireless video streaming with fountain codes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |