当我们调试WebRTC web客户端时，经常会打开chrome://webrtc-internals/这个页面，在这里我们可以看到音视频流的各种统计。今天我们就来看下其中的一个统计参数：抖动（jitter）。 什么是抖动 在网络传输中，每个包从发送端到接收端的时延都是不相同的，而jitter就是用来衡量这种不同。一般在发送端，数据包发送时间间隔是相同的，也就是均匀发送数据，但是传输过程中由于各种情况，例如拥塞，丢包，网络错误等，接收端收到的数据包间隔就会不一样，可能一会大，一会小，导致时延发生变化，这个时延的变化程…

最近更新了M89代码，看了下Release Notes，有几个需要关心的地方。 Plan B SDP语法后续处理计划 WebRTC 1.0已经正式成为W3C标准，推荐使用标准SDP格式：Unified Plan，主流浏览器基本都支持Unified Plan SDP。Plan B SDP后续将会不赞成使用，直到移除掉。官方后续时间计划如下： M89 (2021.02)：在开发者控制台增加不赞成使用警告 M93 (2021.08): Plan B被移除掉, 但是增加了选项，可以延长移除的截止日期 M96 (2022.0…

系统要求 系统：Ubuntu 16.04及以上（本文Ubuntu 18.04） 磁盘空间：至少6.4 GB磁盘空间 安装工具 [crayon-647ca7cc27f9d677906882/] 安装depot tools [crayon-647ca7cc27fa2192932927/] 获取代码 [crayon-647ca7cc27fa3587823927/] 安装依赖 [crayon-647ca7cc27fa4758430962/] 生成Ninja工程文件 WebRTC默认使用Ninja作为编译系统，Ninja工程…

当我们上行推Simulcast流的时候，会发现Simulcast层数会时不时变化，本来是大小流（大小两个分辨率）两层，但是变为只有一层小流了，后面又恢复为两层了，如果我们服务端支持Simulcast的话，这就成为一个棘手问题。 例如我们团队的WebRTC产品，客户端默认会启用Simulcast，上行推送多个不同分辨率的流到服务端，服务端下行会依据带宽估计值，自动选择某个分辨率的流给订阅客户端。假设此时下行带宽足够，服务端会推送大流。但是对于上行客户端来说，因为某种原因，Simulcast层数减少为一层，只剩一路小流…

RTP Header RTP协议中，RTP Header（报头）包括固定报头（Fixed Header）与报头扩展（Header extension，可选）。 RTP Fixed Header结构如下，其中前12字节是每个RTP包必须包含的。 [crayon-647ca7cc2b3c6212522186/] 但是这Fixed Header携带的信息满足不了更复杂的需求。所以引入了RTP Header Extension，可以携带更多的信息。 RTP Header Extension 如果RTP Fixed Head…

在WebRTC中，对于音频丢包，目前有三种丢包恢复方案： 带内FEC 带外FEC NACK 本文介绍其中最简单的带内FEC。带内FEC属于WebRTC中默认启用的功能，由Opus编解码器实现，经过我们测试，30%随机丢包率下语音聊天，仍有不错的质量。不过单一靠带内FEC是无法实现更高的抗丢包要求，例如突发丢包环境或者30%以上随机丢包率，这也是各个厂商的优化点。 Opus编解码器 Opus编解码器其实是一种混合音频编解码器，融合了SILK与CELT两种编解码器。 SILK编解码器 由Skype开发 使用线性预测 适…

本来想写篇文章分析下WebRTC拥塞控制中的BBR算法代码，不过更新最新代码后发现BBR相关代码已经被移除了，所以也没必要了。WebRTC中对应的代码提交如下： [crayon-647ca7cc2e491569875293/] 给出的理由是WebRTC中性能表现很糟糕，BBR得等到以后我研究完QUIC协议再专门分析了。

系统要求 系统：Ubuntu 18.04 磁盘空间：至少16GB磁盘空间 安装工具 [crayon-647ca7cc2fc24280455044/] 安装depot tools [crayon-647ca7cc2fc29940289187/] 获取代码 [crayon-647ca7cc2fc2b910054272/] 依赖安装 [crayon-647ca7cc2fc2c491119850/] 编译 直接使用aar编译工具编译，这里我们指定编译armeabi-v7a与arm64-v8a两种架构。 [crayon-64…