WebRTC Peer Connection Example – Server

by walter

Overview 启动了一个 peerconnection server，也就是一个简单的 web server 用来在两个 client 之间交换信令，比如 SDP, ICE candidate 启动了两个 peerconnection client, 直接连接进行音频和视频媒体数据的传输 Windows peerconnection example peerconnection server server 比较简单，启动一个 HTTP server, 接受 client 的连接， 将接收的数据在 client 之间进行交换 两个 client 都连接到 server 上， 发送 HTTP 请求 /signin ， server 把它作为一个成员(ChannelMember)加到内存中的成员列表中(PeerChannel.members) 这里有一个蹩脚的设计， 由于 server 提供的是 Http 服务，它不会主动发起请求到 client 总是等 client 来要数据(/wait)，server 发现有消息缓存在内部队列(ChannelMember.queue_)中，它才把消息以 HTTP […] →Read more

WebRTC 源码阅读笔记之AcknowledgedBitrateEstimator

by walter

AcknowledgedBitrateEstimatorInterface 确认的比特率估算器接口 class AcknowledgedBitrateEstimatorInterface { public: static std::unique_ptr<AcknowledgedBitrateEstimatorInterface> Create( const WebRtcKeyValueConfig* key_value_config); virtual ~AcknowledgedBitrateEstimatorInterface(); virtual void IncomingPacketFeedbackVector( const std::vector<PacketResult>& packet_feedback_vector) = 0; virtual absl::optional<DataRate> bitrate() const = 0; virtual absl::optional<DataRate> PeekRate() const = 0; virtual void SetAlr(bool in_alr) = 0; virtual void SetAlrEndedTime(Timestamp alr_ended_time) = 0; }; AcknowledgedBitrateEstimator 确认的比特率估算器 class AcknowledgedBitrateEstimator : public AcknowledgedBitrateEstimatorInterface { […] →Read more

WebRTC 源码阅读笔记之 AlrDetector

by walter

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 […] →Read more

WebRTC 源码阅读笔记之传输层反馈 TransportPacketsFeedback

by walter

TransportPacketsFeedback 发送方将自己保存的包信息结合接收方反馈的接收消息 struct TransportPacketsFeedback { TransportPacketsFeedback(); TransportPacketsFeedback(const TransportPacketsFeedback& other); ~TransportPacketsFeedback(); //反馈的时间 Timestamp feedback_time = Timestamp::PlusInfinity(); //第一个没有响应的包的发送时间 Timestamp first_unacked_send_time = Timestamp::PlusInfinity(); //发送过的数据包大小 DataSize data_in_flight = DataSize::Zero(); //先前发送过的数据包大小 DataSize prior_in_flight = DataSize::Zero(); //反馈的数据包接收结果 std::vector<PacketResult> packet_feedbacks; // Arrival times for messages without send time information. std::vector<Timestamp> sendless_arrival_times; //将上述的反馈结果进行分类 std::vector<PacketResult> ReceivedWithSendInfo() const; std::vector<PacketResult> LostWithSendInfo() const; std::vector<PacketResult> PacketsWithFeedback() const; std::vector<PacketResult> […] →Read more

bandwidth probe and estimation

by walter

1. 什么时候会触发探测 1）network available at startup 在启动时网络连通时 2）enable periodic alr probing 启用了定时 ALR 探测 3）large drop in estimated bandwidth 发现评估的带宽有大幅衰减 4) probing results indicate channel has greater capacity 探测结果揭示有更大的容量 2. 带宽探测的配置 These parameters configure the initial probes. First we send one or two probes of sizes p1 start_bitratebps and p2 start_bitratebps. Then whenever we get […] →Read more

How to add log to log file in WebRTC library

by walter

先写一个 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 […] →Read more

Google Congestion Control 实现分析之二

by walter

总体流程 当收到 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 […] →Read more

Google Congestion control 的实现分析之一

by walter

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 当 […] →Read more

拥塞控制技术笔记二：Transport wide Congestion control

by walter

Abstract 拥塞控制技术的笔记二: TWCC Authors Walter Fan  Category     learning note   Status WIP Updated 2022-2-12 概述 前面回顾拥塞控制的一些理论 拥塞控制技术笔记一: 理论篇, 接下来再回顾 WebRTC 中应用较广的 Google 提出来的 GCC(Google Congestion Control), 它有两个版本： GCC v1: 通过 RTP abs_send_time header 和 RTCP REMB message 扩展，基于丢包和延迟估算带宽占用和是否有拥塞，从而调整媒体流的发送速率，主要的估算和决策在接收方，采用了卡尔曼滤波 GCC v2: 通过 RTP transport wide cc sn header 和 RTCP transport feedback message 扩展，基于丢包和延迟估算带宽占用和是否有拥塞，从而调整媒体流的发送速率，主要的估算和决策在发送方，采用了线性回归和最小二乘法 下面来重点讲讲 GCC v2. 它首先定义了对 […] →Read more

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

by walter

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 用户对视频的清晰度基本满意，有些人能感知到视频图像信息的丢失 < […] →Read more