整理归纳写过的WebRTC系列研究文章。本系列文章专注WebRTC底层技术研究。 版权声明：本系列文章全部原创。欢迎指正文章中的错误。 基础入门 音视频开发入门：音频基础 音视频开发入门：视频基础 WebRTC音视频传输基础：NAT穿透 基础概念 WebRTC研究：MediaStream概念以及定义 Webrtc Glossary：查阅各种WebRTC相关概念 开始放弃。。。 编译 Windows平台WebRTC编译（持续更新） Windows平台WebRTC编译-VS2017 Linux平台WebRTC编译 We…
目前H265应用越来越广泛，很多设备都支持硬件加速的H265编解码。作为最常见的音视频终端，Chrome在过去一直都没有H265支持的，毕竟不是AV1那样的亲儿子。人们为了让Chrome完整支持H265，用上了各种招式，例如传输上，用到了datachannel/WebTransport传输H265码流，解码上用到了wasm。 在Native端，要支持H265，得自己魔改WebRTC代码，例如第三方开源WebRTC库：Intel的OWT。现在这些状况就要改变了，目前Chrome已经支持H265硬解，WebRTC上也开…
在Webrtc中存在两种不同的audio level定义，本篇文章我们将介绍下这两种不同的audio level。 AudioDeviceBuffer中的level 在WebRTC中通过AudioDeviceBuffer传递采集播放数据，这里我们将介绍AudioDeviceBuffer中的audio level相关情况。首先先简单介绍下AudioDeviceBuffer在采集播放过程的作用。 音频采集 音频采集模块通过调用AudioDeviceBuffer的SetRecordedBuffer与DeliverReco…
系统要求 磁盘空间：至少5.6 GB磁盘空间（带IOS支持） 准备工作 需要Xcode 9以及以上版本。 对于外网访问，我这里用的是v2rayu，在终端执行如下代理设置： [crayon-673e9d1ec21b3013711944/] 安装depot tools [crayon-673e9d1ec21b8399565302/] 获取代码 [crayon-673e9d1ec21ba083117632/] 如果中间意外中断，执行gclient sync即可。 生成Ninja工程文件 WebRTC默认使用Ninja作为…
RTP时间戳 RTP固定报头中，带有4字节大小的时间戳。 [crayon-673e9d1ec375a681334805/] RTP时间戳一般以采样频率为单位。相邻两帧的时间戳增量为： RTP时间戳分为绝对时间戳跟相对时间戳。本文主要介绍这个时间戳是如何产生的。 视频RTP时间戳产生 由于视频每帧间隔也就是时间差不是稳定的，无法使用固定的时间戳增量计算时间戳，所以视频使用当前帧采集的NTP时间作为时间戳计算基础，也就是使用绝对时间戳表示。 采集阶段 调用set_timestamp_ms(rtc::TimeMillis…
今天我们来看下chrome://webrtc-internals/页面中的一个重要统计参数：丢包率（Fraction lost）。 什么是丢包率 丢包率这个概念我想大家再熟悉不过了，一般来说，丢包率是指所丢失数据包数量占所发送数据包的比例。丢包率也是衡量网络性能的一个指标，我们通常使用丢包率判断当前网络质量，不过丢包也分为拥塞丢包，随机丢包等，随机丢包情况下，我们不能通过得到的丢包率认为当前网络质量差，发生拥塞。这也是现在很多拥塞控制算法不使用丢包率作为主要衡量指标的原因。 ping命令是最常见的一种估计丢包率的方…
丢包检测与重传作为WebRTC中一个抗弱网机制，对提高QOS起了很大作用。WebRTC中目前主要靠NACK机制实现丢包检测与重传，接收端判断丢包情况并记录，然后通过NACK RTCP报文（RFC 4585）反馈丢包信息给发送端，发送端根据NACK报文信息进行包的重传。 NACK机制针对的是某个SSRC的单独流，对于某个SSRC流，对于一个包N，接收端要检测它是否丢了，需要前面收到的该流的包N-1，以及后面收到该流的包N+1的信息，通过检测N-1以及N+1间是否有空隙判断N是否丢了。如果因为一些特殊原因，包N+1到晚…
自从去年4月后，由于临时接手了离职音频算法工程师的工作，所以一直忙于音频处理的研究工作，同时解决产品上音频相关问题。由于要学的内容很多，很难有空余时间，不知不觉把博客给落下了。进入2022年，经过去年一段时间的潜心修炼，目前对WebRTC整个音频处理有了更深入的认识，当然，空余时间也多了些，所以准备继续更新博客，也把没回复的评论过下，找个时间回复。 这段消失的时间，自己总结起来有三方面收货： 1）加深了音频3A算法的熟悉，尤其是AEC3算法内部处理流程，以及特定场景下回声问题排查以及修复，例如采集丢音，采集播放抖动…
本篇文章主要从自己前几个月遇到的一个小问题引出。 问题背景 之前使用Web浏览器播放做测试，发现升级Chrome 87后播放视频会卡，排查服务端下行处理日志发现，带宽估计模块异常，如下是部分异常日志： [crayon-673e9d1ec6464420305209/] 由于下行带宽估计会作用到Pacing模块，带宽估计的异常触发Pacing模块发送异常，从而导致视频卡顿。明明最近没有优化服务端带宽估计处理，哪里出错了呢？ 通过异常日志可以很容易发现是反馈的Transport Feecback报文异常，Transpor…
最近评论
Van 发布于 33 分钟前（11月21日）
cc 发布于 6 天前（11月15日）
haig 发布于 4 周前（10月25日）
Kris 发布于 1 个月前（10月21日）
Kris 发布于 1 个月前（10月21日）