在棋牌游戏中，一起打牌的玩家有吹牛唠叨的社交需求。在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 增加视频旋正功能一文中有更详细的介绍）：
顾名思义，VAD（Voice Activity Detection）算法的作用是检测是否是人的语音，它的使用
范围极广，降噪，语音识别等领域都需要有vad检测。vad检测有很多方法，这里我们之介绍一
下webrtc里面的vad检测。
webrtc的vad检测原理是根据人声的频谱范围，把输入的频谱分成六个子带
（80Hz~250Hz，250Hz~500Hz,500Hz~1K,1K~2K,2K~3K,3K~4K。） 分别计算这六个子带的、
能量。然后使用高斯模型的概率密度函数做运算，得出一个对数似然比函数。对数似然比分为
全局和局部，全局是六个子带之加权之和，而局部是指每一个子带则是局部，所以语音判决会
先判断子带，子带判断没有时会判断全局，只要有一方过了，就算有语音。
Medooze作为WebRTC流媒体服务器，实现了将WebRTC/RTP流的录制为文件，以及将文件转换为RTP流。
mp4recorder.cpp 包含2个类：MP4Track和MP4Recorder，下面一个个分析。
MP4录制功能由MP4V2库提供支持。
一. VAD
1. 什么是VAD
VAD，也就是语音端点检测技术，是Voice Activity Detection的缩写.
这个技术的主要任务是从带有噪声的语音中准确的定位出语音的开始和结束点，因为语音中含有很长的静音，也就是把静音和实际语音分离开来，因为是语音数据的原始处理，所以VAD是语音信号处理过程的关键技术之一。
语音识别系统在识别或者声学模型训练阶段所遇到的第一个技术就是端点检测，把静音和噪声作为干扰信号从原始数据中去除，并且端点检测对于语音识别系统的性能至关重要。
静音抑制，又称语音活动侦测。静音抑制的目的是从声音信号流里识别和消除长时间的静音期，以达到在不降低业务质量的情况下节省话路资源的作用，它是IP电话应用的重要组成部分。静音抑制可以节省宝贵的带宽资源，可以有利于减少用户感觉到的端到端的时延。
2. VAD的作用
现在流行的语音识别系统大部分，或者是相当一部分都是基于统计和训练的原理所构建的系统，因此对数据来源和训练环境都是很敏感的。在识别的过程中，经常存在实际语音因背景噪声的干扰而与训练失配的情况，实际这也是造成语音识别系统鲁棒性差的一个根本原因（另一个主要的是无法处理非预期的输入），从而导致识别错误，性能下降。哪怕是两段内容上是完全一致的语音信号，可能由于语速不一样，所以语音信号的时间也不相同，音素之间的时间间隙也就不一样，对于时变而非平稳的语音信号来说，其特征就完全不相同了。有音素之间的间隙，也有静音和语音本身的间隙，为了对数据从时间上进行相对的校准，语音端点检测技术就应运而生了，因此端点检测技术可以决定这种校准的相对精度，使得同一内容的特征更趋于相同，当然，一般情况下是不可能完全相同的。大量研究表明，如果环境是安静的环境，没有太多背景噪声，此时语音识别系统的主要错误来源于端点检测技术不精确。
但在实际应用中，不可能没有背景噪声，另外由于麦克风的录制和信号增益也会带来噪声，所以语音识别系统的错误是由多方面影响的，至少包括：端点检测、特征提取、语音模型、声学模型、解码器等多个方面。
对播放器架构演进、流媒体存储传输、视频编解码标准及图像声音信号处理，既对数学要求较高又与当时全民IT热相结合的专业——(计算机)信息安全，精妙绝伦的数论及密码学。既能应用密码学的知识技能又能和声色并茂的多媒体场景结合起来的信息隐藏和数字水印，音视频技术是互联网品质生活的连接器。连接器”的另一头则连接且聚合着信息论、最优化理论、图形图像学、声学、人类视觉系统等一众根基深厚、源远流长的学派。
-- 多媒体技术
基础知识方面推荐岗萨雷斯的《数字信号处理》，东南大学的《信息论与编码》；
编码基础方面推荐Wiley的《THE H.264 ADVANCED VIDEO COMPRESSION STANDARD》或国内毕厚杰老师的《新一代视频压缩编码标准H.264》；
最新的标准可以看相关的标准文档。
部署WebRTC的媒体服务器有两个主要挑战，从一台服务器开始扩展，并且优化参加会议的用户的媒体延迟。尽管简单的碎片化方法像‘将X会议中的所有用户发送到服务器Y’容易实现水平扩展，在用户体验中，媒体延迟是一个关键因素，在这方面，此方法还远远不能达到最优效果。
将视频会议分布在距离用户很近的许多服务器上并且保持相互连接，同时解决了两个问题。本文深度描述了级联SFU存在的问题并且展示了解决方法和遇到的其它问题。
实时交流的App非常依赖网络环境，例如吞吐量，延迟，丢失。低比特率导致低视频质量，导致了视频音频中的传输延迟更高。丢包可以导致视频跳帧，进而导致‘波浪音’和视频冻结。
由于这些原因，在会议中，在两个端点之间选择最优路径是很重要的。当只有两个参与者时，这很直接—WebRTC使用ICE协议在两端建立连接，交换多媒体。如果可能的话，两端直接连接，不然的话，在少数情况下使用 TURN传递服务器。WebRTC支持分解域名来获得 TURN服务器地址，这使得选择基于DNS的本地 TURN服务器相对简单，例如，使用AWS Route53的布线选项。
然而，当一个视频会议的参与者通过中心媒体服务器来发送时，情况变得更复杂。许多WebRTC服务像Hangouts，appear.in, Slack和meet.jit.si，使用SFU来在参与者人数多于3人时更有效的传递音频视频。
