const std::unique_ptr<CallStats> call_stats_;
const std::unique_ptr<ReceiveTimeCalculator> receive_time_calculator_;
const std::unique_ptr<SendDelayStats> video_send_delay_stats_;
const Timestamp start_of_call_;
// TODO(bugs.webrtc.org/11993) ready to move stats access to the network
// thread.
ReceiveStats receive_stats_ RTC_GUARDED_BY(worker_thread_);
SendStats send_stats_ RTC_GUARDED_BY(send_transport_sequence_checker_);
const std::unique_ptr<BitrateAllocator> bitrate_allocator_;
// `last_bandwidth_bps_` and `configured_max_padding_bitrate_bps_` being
// atomic avoids a PostTask. The variables are used for stats gathering.
std::atomic<uint32_t> last_bandwidth_bps_{0};
std::atomic<uint32_t> configured_max_padding_bitrate_bps_{0};
NetworkState audio_network_state_ RTC_GUARDED_BY(worker_thread_);
NetworkState video_network_state_ RTC_GUARDED_BY(worker_thread_);
// TODO(bugs.webrtc.org/11993): Move aggregate_network_up_ over to the
// network thread.
bool aggregate_network_up_ RTC_GUARDED_BY(worker_thread_);
// Schedules nack periodic processing on behalf of all streams.
NackPeriodicProcessor nack_periodic_processor_;
ReceiveSideCongestionController receive_side_cc_;
// Note that `task_safety_` needs to be at a greater scope than the task queue
// owned by `transport_send_` since calls might arrive on the network thread
// while Call is being deleted and the task queue is being torn down.
const ScopedTaskSafety task_safety_;
// Caches transport_send_.get(), to avoid racing with destructor.
// Note that this is declared before transport_send_ to ensure that it is not
// invalidated until no more tasks can be running on the transport_send_ task
// queue.
// For more details on the background of this member variable, see:
// https://webrtc-review.googlesource.com/c/src/+/63023/9/call/call.cc
// https://bugs.chromium.org/p/chromium/issues/detail?id=992640
RtpTransportControllerSendInterface* const transport_send_ptr_
RTC_GUARDED_BY(send_transport_sequence_checker_);
// Declared last since it will issue callbacks from a task queue. Declaring it
// last ensures that it is destroyed first and any running tasks are finished.
const std::unique_ptr<RtpTransportControllerSendInterface> transport_send_;
bool is_started_ RTC_GUARDED_BY(worker_thread_) = false;
RTC_NO_UNIQUE_ADDRESS SequenceChecker sent_packet_sequence_checker_;
absl::optional<rtc::SentPacket> last_sent_packet_
RTC_GUARDED_BY(sent_packet_sequence_checker_);
RTC_DISALLOW_COPY_AND_ASSIGN(Call);
2022的版本,只在接收端做估计即可?
对外API封装在ReceiveSideCongestionController类中,顾名思义这一个基于接收端的拥塞控制算法。ReceiveSideCongestionController 类的构造函数,用于创建一个接收端拥塞控制器对象,以保证数据传输的稳定性和可靠性。该类对象需要提供时钟、传输反馈信息发送函数、REMB 消息发送函数和网络状态估计器等信息,用于进行拥塞控制和比特率调整等操作。
LearningWebRTC: 拥塞控制 大神也是这么认为的:
在接收端:ReceiveSideCongestionController则把包的大小和到达时间转发给RemoteBitrateEstimatorProxy,然后以RTCP RTPFB包发给发送端。
在发送端:收到RTCP RTPFB包后,转给SendSideCongestionController并在DelayBasedBwe里完成带宽估计。