本系列介绍Webrtc的agc算法。webrtc的agc算法对各种情况作了较为详尽的考虑，而且使用了的定点数的方法来实现，因此内容比较多。尽量再这几篇文章中描述清楚。
一、AGC模块的结构与简介
较新的webrtc已经把原来的agc模块移动到了一个叫做legacy的文件夹。这个回头再写文章详细介绍。我还是从旧的agc算法开始讲起。Webrtc 的AGC算法的结构如下
｜–\include |–gain_control.h
agc—｜–analog_agc.c
｜–analog_agc.h
｜–digital_agc.c
｜–digital_agc.h
音频方面的开源项目很多很多。
最知名的莫过于谷歌开源的WebRTC,
其中的音频模块就包含有
AGC自动增益补偿(Automatic Gain Control)
自动调麦克风的收音量，使与会者收到一定的音量水平，不会因发言者与麦克风的距离改变时，声音有忽大忽小声的缺点。
ANS背景噪音抑制(Automatic Noise Suppression)
探测出背景固定频率的杂音并消除背景噪音。
AEC是回声消除器(Acoustic Echo Canceller)
对扬声器信号与由它产生的多路径回声的相关性为基础，建立远端信号的语音模型，利用它对回声进行估计，并不断地修改滤波器的系数，使得估计值更加逼近真实的回声。然后，将回声估计值从话筒的输入信号中减去，从而达到消除回声的目的，AEC还将话筒的输入与扬声器过去的值相比较，从而消除延长延迟的多次反射的声学回声。根椐存储器存放的过去的扬声器的输出值的多少，AEC可以消除各种延迟的回声。
人们所熟知的图像方面的3A算法有：
AF自动对焦(Automatic Focus)
自动对焦即调节摄像头焦距自动得到清晰的图像的过程
AE自动曝光(Automatic Exposure)
自动曝光的是为了使感光器件获得合适的曝光量
AW自动白平衡(Automatic White Balance)
白平衡的本质是使白色物体在任何光源下都显示白色
与之相对应的音频方面的3A算法是:
AGC自动增益补偿(Automatic Gain Control)
自动调麦克风的收音量，使与会者收到一定的音量水平，不会因发言者与麦克风的距离改变时，声音有忽大忽小声的缺点。
ANS背景噪音抑制(Automatic Noise Suppression)
探测出背景固定频率的杂音并消除背景噪音。
AEC是回声消除器(Acoustic Echo Canceller)
对扬声器信号与由它产生的多路径回声的相关性为基础，建立远端信号的语音模型，利用它对回声进行估计，并不断地修改滤波器的系数，使得估计值更加逼近真实的回声。然后，将回声估计值从话筒的输入信号中减去，从而达到消除回声的目的，AEC还将话筒的输入与扬声器过去的值相比较，从而消除延长延迟的多次反射的声学回声。根椐存储器存放的过去的扬声器的输出值的多少，AEC可以消除各种延迟的回声。
图像方面的算法就不多说了，图像方面的3a算法，本人都实现了。
自动白平衡的主要思路，就是如何判断图像是否偏色，偏色后如何修复的问题。
常见的有直方图均衡，自动对比度，自动色阶等等。
自动曝光也是要做曝光评估，常见的有gama调节等等。
后续有时间，再陆续贴出相应的代码。
主要用于评估一定长度音频的音量强度，
而分析之后，很多类似的需求，肯定是做音频增益，提高音量诸如此类做法。
不过在项目实测的时候，其实真的很难定标准，
到底在什么样的环境下，要增大音量，还是降低。
在通讯行业一般的做法就是采用静音检测，
一旦检测为静音或者噪音，则不做处理，反之通过一定的策略进行处理。
这里就涉及到两个算法，一个是静音检测，一个是音频增益。
增益其实没什么好说的，类似于数据归一化拉伸的做法。
静音检测 在WebRTC中 是采用计算GMM (Gaussian Mixture Model,高斯混合模型)进行特征提取的。
在很长一段时间里面，音频特征 有3个主要的方法，
GMM ,Spectrogram (声谱图), MFCC 即 Mel-Frequency Cepstrum(Mel频率倒谱)
恕我直言,GMM 提取的特征，其鲁棒性 不如后两者。
也不多做介绍，感兴趣的同学，翻翻 维基百科 ,补补课。
当然在实际使用算法时，会由此延伸出来一些小技巧。
例如，用静音检测 来做音频裁剪，或者搭配音频增益做一些音频增强之类的操作。
1. 可以成功检测到最低能量的语音(灵敏度)。
2. 如何在多噪环境下成功检测（漏检率和虚检率）。
漏检反应的是原本是语音但是没有检测出来，而虚检率反应的是不是语音信号而被检测成语音信号的概率。相对而言漏检是不可接受的，而虚检可以通过后端的ASR和NLP算法进一步过滤，但是虚检会带来系统资源利用率上升，随之系统的功耗和发热会进一步增加，而这会上升为可移动和随声携带设备的一个难题。
unimrcp中vad算法的诸多弊端，但是有没有一种更好的算法来取代呢。有两种方式 1. GMM 2. DNN。
其中鼎鼎大名的WebRTC VAD就是采用了GMM 算法来完成voice active dector。重点介绍WebRTC VAD算法。介绍WebRTC的检测原理。
首先呢，我们要了解一下人声和乐器的频谱范围，下图是音频的频谱。
0 概述
VAD(Voice Activity Detection), 活动语音检测技术在语音信号处理有着重要的作用，如语音增强中估计噪声、语音识别中进行语音端点检测，在语音信号传输中用于非连续传输等等。
本文全面解析WEBRTC 中VAD 算法，该算法主要原理是将信号在频谱上进行子带划分为 80~ 250Hz，250~ 500Hz，500Hz~ 1K， 1~ 2K，2~ 3K，3~4KHz ，6个频带，计算每个频带能量为特征；通过假设检验，构建了噪声和语音两个假设，从而对每个子带构建由2个高斯分布组合的噪声和语音的混合高斯分布模型。通过极大似然估计对模型进行自适应学习优化，并通过概率比判决推断。
该算法重点涉及了子带划分技术、极大似然估计、假设检验等知识，本文将通过信号与系统、统计学习的知识解析代码中所蕴含的数学。
1 子带划分滤波器 SplitFilter
1.1 全通滤波器 AllPassFilter
窄带高清是阿里云视频云的技术品牌，是属于内容自适应编码里的。窄带高清是修复增强 + 压缩的问题，主要目标是追求质量、码率、和成本的最优均衡。在这个方向我们有两代不同版本。
第一代是均衡版，主要作用是如何用最少的成本去实现自适应的内容处理和编码，达到质量提升同时节省码率的目的。所以，我们在窄高 1.0 充分利用编码器里的信息帮助视频处理，即成本很小的前处理方法，从而实现低成本的自适应内容处理和编码。同时，在编码器里，主要时间是基于主观的码控。
第二代（窄高 2.0），与窄高 1.0 相比会有更多的、更充分的、复杂度更高的技术来保证自适应能力，同时我们在窄高 2.0 里增加了修复能力，比较适用于高热内容，比如优酷世界杯。对这种重要的比赛用窄高 2.0 进行处理，在质量提升的同时，码率节省也更多，具体内容我在后面会一一展开。
2010 年毕业于华中科技大学，此后投身多媒体方向的技术开发，从流媒体、视频编码、视频处理到质量评价均有涉及，并从零开始打造了一款广泛商用的视频编码器及其前后处理系统。加入阿里云视频云后，负责视频编码与增强算法，团队聚焦在视频编码、视频前后处理以及质量评价方向，并重点研发演进窄带高清技术。
此次作为 LiveVideoStackCon 2021 的讲师，王豪与我们分享其对编码优化的思考与发现。
我个人的技术栈一直聚焦在视频编码和处理方向，也一直在思考，在这个方向上，我们短期和长期的布局是什么，中短期布局如何保证竞争力，以及长期布局如何避免系统性踏空。
利用 AI 辅助视频压缩是业界非常关注的方向，它有这几种思路：
这其中，我最关注 “基于标准编解码器的视频编码与处理联合优化”。针对视频后处理，还有如何进行编码决策优化（包括模式和码率），同时扩展到分层编码，这个方向是整个端云联合优化的核心，对工业界应用有很大价值，希望到时候和大家一起探讨。
变分辨率在弱网场景的实际应用中非常常见，网络状况不好的时候降低分辨率可以降低码率，减少块效应，网络好的时候增加分辨率可以提升清晰度及主观体验。
目前主流的视频编码标准，比如 H.264、H.265，在编码过程中如果要进行分辨率切换，则必须要先编码一个 I 帧，而 I 帧只能使用帧内预测，编码效率低下。这在弱网变分辨率的时候就容易造成卡顿。下图中展示了每秒钟切换分辨率的码率波动效果，高低两个分辨率，每秒钟切换一次。
因为有些朋友不是做服务器的，我还是先介绍下 RTC 服务是什么吧。
直播经过这些年的发展，大家都理解需要后端服务，比如 OBS 推流，是不能直接推给播放器的，而是经过 CDN 转发，CDN 就是直播的后端服务了。
RTC 是大不相同的，比如 WebRTC 本身设计是通话，通话场景大部分时候都是一对一的对话，所以 WebRTC 设计了多种传输方式，比如直接 P2P、通过 STUN 转发、通过 SFU 或 MCU 转发。
如果只是跑 DEMO，那么不用 RTC 服务器，直接 P2P 也是可以跑起来的。真实线上，肯定是要经过服务器，现在使用最广的是 SFU 转发。主要原因如下：
各家云厂商都有自己的后端服务，比如阿里云的 GRTN，声网的 SD-RTN 等等。实际上传输网络并不等于传输服务器，而是一个传输的系统，包括调度、路由、协议处理、发布和维护、问题排查、数据分析等等。
AliRTC（阿里云 RTC）的传输网络，传输协议使用 GRTN，除了 GRTN (CDN) 的网络，我们还扩展实现了 GRTN (Tenfold)；GRTN (Tenfold) 补充了 BGP 专线、ENS、专有云网络、第三方云支持 K8S 的云网络等，适应多种不同场景的传输要求。
其中 GRTN (Tenfold) 就是基于 SRS 做的，增加了很多能力，有些已经反馈给了 SRS 社区。
