Archive


Category: WebRTC

  • WebRTC 源码阅读笔记之 AlrDetector

    Overview ALR（Application limited region detector）的基本原理就是 SentBitRate/EstimatedBitRate 的百分比与 kAlrStartUsagePercent（50）做比较，当小于该值认为网络受限，需要启动 probe 重新探测带宽，当大于 kAlrEndUsagePercent（80），认为网络恢复， 停止进行启动下次 probe 探测 AlrDetectorConfig 发送流量比率(sent_bitrate/estimated_bitrate) 作为网络容量的函数，用于确定应用程序受限区域 ALR(Application-Limited Region)。 ALR 区域在带宽剩余率大于 kAlrStartUsageRatio (默认为0.8) 时开始，在带宽剩余率大于 kAlrEndUsageRatio (默认为 0.5) 时结束。 注意： 带宽剩余率 = 1 – send_bitrate/estimated_bitrate 在对应用有限区域的 BW 调整进行有效微调之前，这是有意做了一些保守的。 struct AlrDetectorConfig { // Sent traffic ratio as a function of network capacity used to determine // application-limited […]

  • How to add log to log file in WebRTC library

    先写一个 LogSink class BweTestLogSink : public rtc::LogSink { public: BweTestLogSink(const std::string& filepath) { m_stream.open(filepath, std::ios::app | std::ios::out | std::ios::in); } ~BweTestLogSink() { m_stream.close(); } void OnLogMessage(const std::string& message) override { //std::cout << message << std::endl; m_stream << message; } private: std::ofstream m_stream; }; 2. 将这个 LogSink 加到 LogMessage 的输出流中 “`cpp //程序开始后 //add timestmap, thread into […]

  • Google Congestion Control 实现分析之二

    总体流程 当收到 Transport Wide CC RTCP report 时候 ，会回调 OnTransportPacketsFeedback 方法 s=>start e=>end s1=>operation: send rtp with TWCC header s2=>operation: receive rtp packet s3=>operation: compose TWCC feedback s4=>operation: send rtcp packet s5=>operation: receive rtcp packet s6=>operation: parse rtcp packet s7=>operation: bandwidth estimate s8=>operation: adjust send bitrate s->s1->s2->s3->s4->s5->s6->s7->s8->e 主要的逻辑在发送方 title WebRTC congestion control v1 participant RtpSender […]

  • Google Congestion control 的实现分析之一

    Overview 影响因素有 Packet loss, RTT 和 OWDV(One Way Delay Varion) 基于丢包的控制器：以丢包率， RTT 和 REMB 消息来估算一个目标发送码率 基于延迟的控制器：以包的到达信息，或者在接收方，或者在发送方接收反馈，估算一个最大的码率，然后传送给基于丢包的控制器 基于丢包的估算是保底的，丢包率大于 10% 就往下降码率，小于 2% 就往上升码率 基于延迟的控制器一开始用的是 Kalman filter, 后来改为 Trendline filter , 便于预测网络变化的趋势 Trendline filter 的输入参数有 Main interface method parameter description OnNetworkAvailability NetworkAvailability 当网络连接有效或无效时 OnNetworkRouteChange NetworkRouteChange 当网络地址更改时 OnProcessInterval ProcessInterval 定时回调，以检查网络 OnRemoteBitrateReport RemoteBitrateReport 当收到 REMB RTCP 消息时回调 OnRoundTripTimeUpdate RoundTripTimeUpdate 当 […]

  • 拥塞控制技术笔记一：理论篇

    Abstract 拥塞控制技术的笔记一 Authors Walter Fan  Category     learning notes   Status WIP Updated 2022-2-10 引言 如果带宽足够的话, 没有拥塞,没有大的延迟和抖动, 那么语音和视频的发送和接收都会很顺滑,一切会很美好. 现实总是很残酷的, 网络会断, 会丢包, 会变慢，在路由节点上会排队，会拥塞，就象城市的环线道路，平常车来车往，道路通畅，一到上下班的时候，大大小小的车辆就象乌龟一样慢慢向前爬。 视频会议需要低延迟和高带宽，可是实际情况中，高带宽是难以保证的，一旦网络出现拥塞，原本就不宽阔的“马路” 堵得更窄，延迟更大。这时候，就需要做拥塞控制 在网络会议中，如果延迟太大，对在线交流就会产生影响。语音会感觉很明显，视频相对迟钝一些。 以视频来说，据研究，大致的关系如下 延迟 感觉 0 ~ 400 毫秒 在交流过程中感觉不到延迟 400 ~ 800 毫秒 能感觉到延迟，但不影响沟通和交流 800 毫秒及以上 能感觉到延迟，并且影响沟通和交流 以一个每秒 24 帧 640*480 分辨率，以 H.264 编码的视频流，视频的比特率和用户感觉的关系如下 比特率 感觉 > 800kbps 用户对视频的清晰度感到满意，感知不到视频图像信息的丢失 480 ~ 800kbps 用户对视频的清晰度基本满意，有些人能感知到视频图像信息的丢失 < […]

  • WebRTC Congestion Control classes

    Module remote_bitrate_estimator class RemoteEstimatorProxy It is used when send-side BWE is enabled: This proxy is instantiated on the receive side. It buffers a number of receive timestamps and then sends transport feedback messages back too the send side. class AimdRateControl A rate control implementation based on additive increases of bitrate when no over-use is detected […]