我的玻璃盒子

近期，百家云 BRTC 实时音视频平台推出了针对华为 HarmonyOS NEXT 系统的原生 RTC SDK，进一步扩大和丰富了 BRTC 产品的产品矩阵，为广大需要 RTC 能力的个人、企业提供了更加丰富的选择，注入新的活力。

本文就如何设计一个完善的音视频录制系统架构，需要考虑的各个方面进行了简单的阐述。尽可能将实时音视频录制系统在各种场景下，不同方案的优劣进行对比说明。相信通过本文的介绍，对您了解实时音视频录制系统会有一个全面的认知。

2020 年 11 月份我曾经发过一篇文章，当时纯粹只是为了体验一下编译过程，没什么实际用途。因为当时公司的产品还在使用 CEF，所以后续就没有继续跟进了。过去一两年的时间，公司的产品已经逐渐从 CEF 过渡开始使用 Electron 了，有些原来在 CEF 上的修改，有些场景可能还是有需要在 Electron 上来修改。所以，最近我又重新编译了一次 Electron。这次的编译比 3 年多那次遇到了更多的问题，这里尽可能逐一记录下来，以便后续参考。这次编译的版本是指定了v20.3.12。

在每次视频推流或拉流结束后，WebRTC都会输出本次视频推拉流的统计报告。其中包含了关于评价本次推拉流质量相关的若干参数。本文的主要目的是介绍视频推流相关的统计指标含义。

本文介绍了 WebRTC 视频流发送统计报告（ReceiveStatisticsProxy）中主要度量指标的含义。文章基于WebRTC M94 版本编写。

注：本文代码基于WebRTC 4472（对应Chromium 91），不保证适用于所有WebRTC版本。在Chrome的 webrtc-internals 里可以看到很多关于媒体流的度量指标。目前Chrome（我用的版本是94）保留了传统（legacy）和WebRTC标准（standard）两种体系的度量数据。其中legacy的数据已经不再更新，也许未来某个时间就会从Chrome中消失了。无论legacy还是standard，对我们日常分析客户端侧的音视频质量数据还是非常重要的。度量数据众多，本文只介绍

Chromium（以及CEF）以及Chrome并没有提供区域捕获功能（注：有一种消息表明Chrome M97可能会添加），但因为公司产品需要，所以就阅读了一下Chromium、WebRTC的源码，上个月花了几天时间，在Windows上为CEF添加了区域捕获功能，版本基于CEF 4472（Chromium 91）。用法也比较简单：const displayMediaOptions = { audio: true, video: true, regionShare: true};const

最近机器总是频繁地蓝屏，重装了Windows 10系统。一开始一度以为是硬件故障了，后来相继安装了21H1 (updated Jul 2021) (x64) 到 1909 (Updated April 2020) (x64) 等多个Win10版本，都是不同概率地发生蓝屏。最后找来2017年下半年的一个Win10版本，安装上，一切太平了，稳得一批。看来我这2018年初买的笔记本（小米笔记本Pro），不配使用最新版本的Win10系统，哈哈。重装系统以后，直接用 ninja 编译 WebRTC 源码，就提示了这

很久没有编译CEF新版本了，最近看到Chrome提到在91版本上，提到有23%的性能提升，原文链接：https://blog.chromium.org/2021/05/chrome-is-faster-in-m91.html，是不是真有这么大改进？所以想试试看。然后理所当然地使用以前自己的编译脚本进行编译，结果又遇到个“奇葩”问题，这里简单记录一下。在使用automate-git.py编译CEF 4472（Chromium 91）的时候，在脚本执行完CEF patch apply以后，突然报错：Gene

注：本文内容基于WebRTC M76分支，部分代码细节可能和后续WebRTC代码有差异。但笔者查看了4324（M88），基本上差异不大，同样适用，但再往后的版本就无法保证了。首先说一句，simulcast的支持，不仅仅是客户端修改就可以了，服务器端也需要修改。Licode、mediasoup都是支持simulcast的。这里只描述了客户端的修改，不涉及服务器端。如果你对simulcast所涉及的两种sdp格式不太熟悉，可以先看看这篇文章：Simulcast and Janus: what’s new?

前段时间处理过一例在Chrome中视频虚拟背景图显示范围不正确的问题，在阅读Chromium源码并结合一些试验后，这里简单记录一下media::VideoFrame这个类其中的与此次问题排查相关的三个属性的含义。media::VideoFrame的代码位于 media\base\video_frame.h(.cc)，下面代码摘抄自其中（Chromium 85，branch 4183）： // The full dimensions of the video frame data. const gf

最近心血来潮想编译一下和CEF同源的Electron源码。虽然已经有很多CEF的经验，但在编译Electron的时候还是遇到了一些小问题，这里简单记录一下。编译工具我是按照Electron提供的 Build Tools 来编译的。因为之前经常编译CEF，所以像 depot_tools、git 这些早就有。然后按照指导，额外安装了 yarn，并且更新了我机器上的 npm 和 node.js版本。编译过程在Electron Build Tools指导页面上，针对init / sync / build 做

这几天在做一些WebRTC音频改进方面的调查工作，在阅读Chromium源码的过程中，就顺便记录下来，便于日后回顾。本文基于Chromium 85源码分析，由于Chromium的快速发展，很有可能不适合于跨度太大的Chromium版本。大家知道Opus内置了两种编码器：CELT和SILK，并且可以针对采样率、采样间隔、码率、通道数……等属性进行设置。创建的参数设置，是从sdp来的。本文的主要目的，是来看看sdp中的信息，是如何对应到native世界里的代码的。Native调用序列：上图中，我保留的起

喔~ 突然发现已经快一年没写过博客了。主要是这一年实在是太忙了，一直没有时间好好整理和规划一些内容。今天打算把自己前段时间在我们公司产品中做的一个小功能的原理拿出来简单讲讲。（注：本文基于Chromium 4183（Chromium 85）源码）背景我们公司的桌面客户端产品是基于Chromium内核的CEF框架（理论上同源的Electron也是适用的），前一段时间和国内某知名计算机视觉和深度学习原创技术公司进行合作，将他们公司的技术应用到我们的桌面客户端产品中来。大家知道，Chromium及其内置的We

这篇文章从WebRTC构造sdp字符串作为入口，一步步地寻找产生video codec的源头