本篇文章主要从自己前几个月遇到的一个小问题引出。 问题背景 之前使用Web浏览器播放做测试，发现升级Chrome 87后播放视频会卡，排查服务端下行处理日志发现，带宽估计模块异常，如下是部分异常日志： [crayon-682c388a68bf3413393610/] 由于下行带宽估计会作用到Pacing模块，带宽估计的异常触发Pacing模块发送异常，从而导致视频卡顿。明明最近没有优化服务端带宽估计处理，哪里出错了呢？ 通过异常日志可以很容易发现是反馈的Transport Feecback报文异常，Transpor…
前段时间看到腾讯云的分享：《WebRTC Insertable Stream 初探与 WebRTC “管道化”》。想不到国内也开始关注这个新特性了，作为一个经常关注WebRTC最新提交代码的人，去年初就关注到了WebRTC Insertable Streams相关代码提交，不过对我这样一个Native Code开发者来说，用途不大，毕竟自己也可以在源码层面实现，获取或者修改自己需要的任何数据。但是这一特性对Web开发者来说用途就大了，给了Web开发者更多的自由与操作性。 WebRTC Insertable Stre…
前面文章介绍了抖动，今天我们来看下chrome://webrtc-internals/页面中的一个重要统计参数：往返时延（RTT）。 什么是RTT 往返时延(round-trip time，RTT) 是网络请求从起点到目的地然后再回到起点所花费的时长（不包括接收端的处理时间）。RTT是分析网络性能的一个重要指标，我们通常使用RTT来诊断网络连接的速度，可靠性以及拥塞程度。 ping命令是最常见的一种估计往返时延的方法。下面是ping Google的示例，底部显示了rtt的不同表示：最小，平均，最大，平均偏差。 [c…
当我们调试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-682c388a6fcaa018520460/] 安装depot tools [crayon-682c388a6fcb1978777056/] 获取代码 [crayon-682c388a6fcb3834984769/] 安装依赖 [crayon-682c388a6fcb5037989655/] 生成Ninja工程文件 WebRTC默认使用Ninja作为编译系统，Ninja工程…
当我们上行推Simulcast流的时候，会发现Simulcast层数会时不时变化，本来是大小流（大小两个分辨率）两层，但是变为只有一层小流了，后面又恢复为两层了，如果我们服务端支持Simulcast的话，这就成为一个棘手问题。 例如我们团队的WebRTC产品，客户端默认会启用Simulcast，上行推送多个不同分辨率的流到服务端，服务端下行会依据带宽估计值，自动选择某个分辨率的流给订阅客户端。假设此时下行带宽足够，服务端会推送大流。但是对于上行客户端来说，因为某种原因，Simulcast层数减少为一层，只剩一路小流…
最近评论
Jeff 发布于 5 天前（05月15日）
Jeff 发布于 5 天前（05月15日）
ztt 发布于 2 个月前（04月05日）
huowa222 发布于 2 个月前（03月26日）
邱国禄 发布于 3 个月前（02月17日）