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

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

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

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

系统：Ubuntu 18.04 安装depot_tools [crayon-600a42de864e0431238628/] 获取代码 [crayon-600a42de864e6035605560/] 依赖安装 [crayon-600a42de864e8772456547/] 编译 直接使用aar编译工具编译，这里我们指定编译armeabi-v7a与arm64-v8a两种架构。 [crayon-600a42de864eb126175173/] 生成的libwebrtc.aar文件文件位于src目录下，编译过程产生的…

数字图像 平时我们看到的视频其实是由一幅幅图像组成，所以先来了解下数字图像。 数字图像由一个个像素组成，是二维图像用有限数字数值像素的表示。如下路所示，我们放大一个图像后，能明显看到一个个像素块： 图像分辨率 水平分辨率指的一幅图像的宽，垂直分辨率指的一幅图像的高。一般说的分辨率用水平分辨率（宽）X 垂直分辨率（高）表示。 常见分辨率有： QVGA:320x240 CIF:352×288 VGA:640x480 HD:1360x768 FHD:1920x1080 WQHD:2560x1440 4K UHD:3840…

首先看下webrtcglossary中的定义。 RED stands for REDundant coding and it is a RTP payload format defined in RFC 2198 for encoding redundant audio or video data. The primary motivation of sending redundant data is to be able to recover packets lost under lossy network co…

WebRTC带宽估计后，得到的结果会存到TargetTransferRate结构体中，然后回调给上层。 [crayon-600a42de86bf1134190103/] 可以看到该结构体有两个估计码率值，本文我们介绍下其中的stable_target_rate，该值在后续的码率分配中有用到，配合target_rate进行相关判断。 在GoogCcNetworkController中，TargetTransferRate结果值按如下得到： [crayon-600a42de86bf7471256641/] 其中push…