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 社区。
WebRTC AEC 存在的问题：
（1）线性部分收敛时间较慢，固定步长的 NLMS 算法对线性部分回声的估计欠佳；
（2）线性部分滤波器阶数默认为 32 阶，默认覆盖延时 132ms，对移动端延时较大设备支持不是很好，大延时检测部分介入较慢，且存在误调导致非因果回声的风险；
（3）基于相干性的帧状态依赖严格的固定门限，存在一定程度的误判，如果再去指导非线性部分抑制系数的调节，会带来比较严重的双讲抑制。
优化的方向：
（1）算法上可以通过学习 speex 和 AEC3 的线性部分，改善当前线性滤波效果；
（2）算法上可以优化延时调整策略，工程上可以新增参数配置下发等工程手段解决一些设备的延时问题；
（3）另外，有一些新的思路也是值得我们尝试的，如开头提到的，既然回声也可以是视为噪声，那么能否用降噪的思路做回声消除呢，答案是可以的。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。
在棋牌游戏中，一起打牌的玩家有吹牛唠叨的社交需求。在MMORPG竞技游戏中，一起并肩作战的队友有团队协同的通讯需求。实时游戏语音是网络游戏的标配，这早已经是业界共识。
现在的问题是，不管是自行研发实时游戏语音方案,还是采用第三方游戏实时语音SDK，都必须要先为游戏量身订造一套解决方案。这套解决方案必须是和游戏本身的用户需求、考量因素、及应用场景紧密结合的。把通用的语音视频通讯方案直接拿来给游戏用是不适合的。
今天，我们就一起来深度聊一聊，怎么针对游戏的应用场景订造游戏实时语音解决方案。
人声场景是指语音通讯中大部分或者全部时间都是人声在说话的场景。典型的例子包括Skype网络电话、和微信语音。音乐声场景是指语音通讯中有相当一部分内容是涉及到音乐和表演等娱乐环节的场景。典型的例子包括花椒直播的连麦K歌海选赛。
游戏实时语音的场景基本是人声在说话。现在，让我们来了解一下人声语音的特点。人类的听力感知范围是从20Hz到20kHz。这个频宽范围被划分成四个频宽类别：窄带、宽带、超宽带和全带。
最近更新了M89代码，看了下Release Notes，有几个需要关心的地方。
WebRTC 1.0已经正式成为W3C标准，推荐使用标准SDP格式：Unified Plan，主流浏览器基本都支持Unified Plan SDP。Plan B SDP后续将会不赞成使用，直到移除掉。官方后续时间计划如下：
M89中RTP payload类型增加了新的值范围：35-65。
首先根据RFC3551，回顾下目前用于标准音视频编码器的RTP payload类型。
我们首先了解一下 RTP H.264 相关的 RFC，下面的内容是对两篇 RFC 的总结：RTP: A Transport Protocol for Real-Time Applications, RTP Payload Format for H.264 Video。
RTP 包结构
包头有固定 12 个字节部分，以及可选的 csrc 和 ext 数据（在为 janus-pp-rec 增加视频旋正功能一文中有更详细的介绍）：
