在 WebRTC 中，交互的两端在建立连接过程中，需要通过 ICE 协议，交换各自的音视频编解码能力，如编解码器和编解码器的一些参数配置，并协商出一组配置和参数，用于后续的音视频传输过程。对于音频，编解码能力的一部分信息从 audio 的 encoder 和 decoder factory 中获取。Audio encoder 和 decoder factory 在创建 PeerConnection

OSI 网络协议模型为什么是 7 层呢？相信不少朋友心中都有这样的疑问。Douglas E. Comer 先生的个人主页上的一篇文章 How the 7-layer reference model was invented 讲述了 OSI 7 层网络协议参考模型的由来。（Douglas E. Comer 先生在网络界的盛名不需多说，相信很多朋友都读过他的非常棒的讲述网络协议的三卷本著作《用 T

本文主要内容来自于 OpenCV-Python 教程 的 OpenCV 中的图像处理 部分，这部分的全部主要内容如下：改变色彩空间学习在不同色彩空间之间改变图像。另外学习跟踪视频中的彩色对象。图像的几何变换学习对图像应用不同的几何变换，比如旋转、平移等。图像阈值学习使用全局阈值、自适应阈值、Otsu 的二值化等将图像转换为二值图像。平滑图像学习模糊图像，使用自定义内核过滤图像等。形态变换了解形态学

WebRTC 的音频数据处理发送的概念抽象层面的完整流程如下：用于控制各个操作系统平台的音频设备，主要用来做音频的采集和播放。 是一个适配和胶水模块，它把的音频数据采集和的音频数据处理及 / 的音频数据编码和发送控制粘起来， 把采集的音频数据送给处理，之后再把处理后的数据给到 / 编码发送出去。 用于做音频数据处理，如降噪、自动增益控制和回声消除等。/ 用于对音频数据做编码，比如 OPUS、AAC

本文梳理 WebRTC 的音频弱网对抗中的 NACK 机制的实现。音频的 NACK 机制在 WebRTC 中默认是关闭的，本文会介绍开启 NACK 机制的方法。

在 Android Java 应用中，一般用管理从平台的音频输入设备采集音频数据所需的资源。音频采集和音频播放密切关系，Android 系统中 Java和AudioTrack在许多方面，都有着很高的相似性，无论是代码的目录组织，还是整个类的接口设计和实现结构，但它们也有着不小的区别。对比来看 Java和AudioTrack的实现，有助于我们对音频的播放和采集做更好地理解。的 Java 代码位于，它

Android 系统的守护进程 audioserver 中运行着多个与音频相关的系统服务，主要包括和，当需要支持 AAudio 的 MMap 模式时，会运行。需要启动服务时，audioserver 程序会 fork 一个进程运行其它那些系统服务，在父进程中运行，并将进程名修改为。

曾经整理过一个 WebRTC 音频发送和接收处理的关键过程，WebRTC Audio 接收和发送的关键过程 ，不过之前的分析是基于比较老的版本做的。分析所基于的应用程序，依然选择 WebRTC 的示例应用 peerconnection_client。这里基于 WebRTC 比较新的 M96 版的代码，再来看下音频发送和接收处理过程。1. 创建 JsepTransportController#0we

事情有点棘手，但这里有一个粗略的描述：QEMUSoundCard：建模一个给定的模拟的声卡SWVoiceOut：建模一个来自 QEMUSoundCard 的音频输出SWVoiceIn：建模一个来自 QEMUSoundCard 的音频输入HWVoiceOut：建模一个主机端的音频输出（后端）HWVoiceIn：建模一个主机端的音频输入（后端）每个声音在采样大小，字节序，速率等方

本文梳理 WebRTC 的音频弱网对抗中的 NACK 机制的实现。音频的 NACK 机制在 WebRTC 中默认是关闭的，本文会介绍开启 NACK 机制的方法。