【webrtc】GCC 7： call模块创建的ReceiveSideCongestionController

• webrtc 代码学习（三十二） video RTT 作用笔记

从call模块说起

call模块创建的时候，会创建

• src\call\call.h
  
• 线程：
  

统计

  const std::unique_ptr<CallStats> call_stats_;

SendDelayStats ： 发送延迟统计

  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_);

nack ？ NackPeriodicProcessor

  // Schedules nack periodic processing on behalf of all streams.
  NackPeriodicProcessor nack_periodic_processor_;

音视频流 ：处理同步？

接收测带宽估计？

  ReceiveSideCongestionController receive_side_cc_;

ReceiveSideCongestionController 会绑定remb 等rtcp包

• 作为一个module 周期执行：
  

RtpStreamReceiverController 解析rtp rtcp的

ssrc

发送侧带宽估计

  // 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);

call 模块可提供rtt bwe 等信息

m114 中 ReceiveSideCongestionController 依然存在

ReceiveSideCongestionController 用于做带宽估计

• WebRTC拥塞控制原理之一基本介绍

• 2022的版本，只在接收端做估计即可？
  

对外API封装在ReceiveSideCongestionController类中，顾名思义这一个基于接收端的拥塞控制算法。ReceiveSideCongestionController 类的构造函数，用于创建一个接收端拥塞控制器对象，以保证数据传输的稳定性和可靠性。该类对象需要提供时钟、传输反馈信息发送函数、REMB 消息发送函数和网络状态估计器等信息，用于进行拥塞控制和比特率调整等操作。

• RemoteEstimatorProxy ： 远程估计代理
• RembThrottler::RembSender remb_sender, // REMB发送器
• NetworkStateEstimator* network_state_estimator); // 网络状态估计器

ReceiveSideCongestionController 对于接收流做拥塞控制

• 对于发送侧的带宽估计，这个类可以直接代理每个接收到的rtp包的信息 发送给发送者。
• 对于接收测的带宽估计，这个类自己就可以本地估计并且发送结果给发送端。

• LearningWebRTC: 拥塞控制 大神也是这么认为的：

• 在接收端：ReceiveSideCongestionController则把包的大小和到达时间转发给RemoteBitrateEstimatorProxy，然后以RTCP RTPFB包发给发送端。

• 在发送端：收到RTCP RTPFB包后，转给SendSideCongestionController并在DelayBasedBwe里完成带宽估计。