发送端NACK实现的核心流程包括RTP报文缓存、RTCP NACK处理和RTP报文重发。发送端通过Pacer发送RTP报文时，会将允许重传的媒体报文存入packet_history_缓存队列，为后续重传提供数据源。当接收端检测到丢包并发送NACK请求时，发送端通过RTPSender::OnReceivedNack处理请求，并调用ReSendPacket重传丢失的RTP报文。关键函数包括RtpSen

WebRTC中前向纠错(FEC)技术通过主动生成冗余数据提升抗丢包能力。文章详细解析了三种FEC方案：Red(简单冗余拼接)、Ulpfec(主流异或冗余)和Flexfec(实验性交织异或)，对比了其原理、优缺点及适用场景。其中Ulpfec作为默认方案支持动态调整冗余度，Flexfec则针对复杂丢包提供更灵活保护。文章还分析了不同编解码器的FEC适配策略，并解读了WebRTC源码中FEC的使能与封装

NACK是ACK的逆向机制，用于通知数据未达。在TCP中，ACK确保可靠传输，而NACK则在丢包时触发重传请求。NACK分为包级重传（RTPFB）和帧级重传（PSFB），后者包括PLI（整帧丢失）、SLI（部分丢失）和RPSI（参考帧丢失）。WebRTC根据丢包程度自动选择策略：优先包级重传，严重时升级为帧级重传。RTCP反馈消息通过包头字段（如FMT、PT）区分类型，RTPFB（PT=205）处

WebRTC 带宽估计（BWE）是决定视频通话质量的关键模块，其算法经历了从基于丢包的被动响应到基于延迟的主动预测的演进。Sender Side BWE 作为最新方案，将计算逻辑迁移至发送端，通过三大核心机制实现动态码率调整：1）兼容旧版本的 REMB 反馈；2）基于丢包率的直接调整（2%-10%丢包率阈值）；3）基于延迟的趋势预测（通过 Trendline 滤波器分析包组延迟）。最终采用三者最小

Transport-cc协议是WebRTC中基于RTCP反馈报文的拥塞控制机制，通过动态调整码率保障实时音视频传输质量。其核心结构包括：1）报头标识字段；2）SSRC源标识；3）控制参数（序列号、包状态计数等）；4）packet chunk状态编码（行程编码Run length或状态向量Status vector）；5）到达时间差recv delta（1/2字节存储）。该协议通过压缩反馈信息实现高

SVC（可适性视频编码）是H.264/AVC的扩展技术，通过时间、空间和质量的灵活分层实现视频流的自适应传输。其核心优势在于"一次编码，多端适配"，有效降低编码开销。时间分层通过帧间预测实现帧率调整，空间分层支持分辨率动态变化，质量分层则允许码率弹性控制。典型应用包括监控视频的多分辨率存储、视频会议的多终端适配以及抗网络丢包场景。OpenH264等开源库已实现SVC编码功能，通

WebRTC中FEC冗余度配置的核心逻辑是动态调整冗余包数量以应对网络丢包。其工作流程为：接收端计算当前丢包率并通过RTCP反馈给发送端；发送端根据历史趋势预判未来丢包率（采用指数平滑等算法），通过查表确定关键帧/普通帧的冗余比例；最终按该比例生成FEC包与媒体包一起发送。整个过程通过定时触发和事件驱动的双链路实现：丢包率计算链路周期性处理网络反馈并调整冗余参数，封装链路则按最新参数为编码后的视频

WebRTC中的RTT（环路延时）及其作用 RTT（Round-Trip Time）是数据从发送端到接收端再返回确认的时间，单位为毫秒（ms）。WebRTC通过解析RTCP协议的RR报告计算RTT，核心流程涉及多模块协作，最终由RTCPReceiver提取字段并计算。RTT直接影响抗丢包策略：低RTT（<100ms）优先使用NACK重传；中RTT（100-300ms）混合NACK和FEC；高

Probe探测算法摘要 Probe探测算法是解决GCC算法"快降慢升"问题的带宽快速探测机制，包含启动阶段和网络变化阶段两个应用场景。该算法通过发送端发送探测数据包并记录发送时间/序列号，接收端反馈接收码率，最终取发送码率与接收码率的最小值作为实际发送码率。核心由ProbeController等5个模块协同实现，采用指数级探测策略（3倍→6倍起始码率）。算法通过比较发送/接收时

文章摘要 PACER模块旨在解决视频数据传输中的网络拥塞问题。由于视频帧大小差异显著，直接发送可能导致网络波动，尤其在WiFi环境下影响通话质量。PACER通过优先级队列管理音频、视频、重传等报文，确保高优先级数据（如音频、重传）优先发送，同时动态调整发送节奏。核心通过NextSendTime和ProcessPackets函数控制发送周期（如固定5ms间隔），实现数据平稳发送，减少延迟和卡顿。优先