游戏实时语音解决方案是怎么炼成的

作者：冼牛，微信xianniu1216，即构科技市场运营总监，北京邮电大学计算机硕士，香港大学工商管理硕士，多年从事语音视频云服务技术研究，专注互动直播技术和实时游戏语音。

 

孟子曰：“独乐乐，不如与人乐乐；与少乐乐，不若与众乐乐。”

如果孟子是游戏发烧友，那么他肯定说：“单机版不如联网玩，独自玩不若游戏语音开黑玩。”

 

在棋牌游戏中，一起打牌的玩家有吹牛唠叨的社交需求。在MMORPG竞技游戏中，一起并肩作战的队友有团队协同的通讯需求。实时游戏语音是网络游戏的标配，这早已经是业界共识。

 

现在的问题是，不管是自行研发实时游戏语音方案,还是采用第三方游戏实时语音SDK，都必须要先为游戏量身订造一套解决方案。这套解决方案必须是和游戏本身的用户需求、考量因素、及应用场景紧密结合的。把通用的语音视频通讯方案直接拿来给游戏用是不适合的。

今天，我们就一起来深度聊一聊，怎么针对游戏的应用场景订造游戏实时语音解决方案。

人声 or音乐声

人声场景是指语音通讯中大部分或者全部时间都是人声在说话的场景。典型的例子包括Skype网络电话、和微信语音。音乐声场景是指语音通讯中有相当一部分内容是涉及到音乐和表演等娱乐环节的场景。典型的例子包括花椒直播的连麦K歌海选赛。

游戏实时语音的场景基本是人声在说话。现在，让我们来了解一下人声语音的特点。人类的听力感知范围是从20Hz到20kHz。这个频宽范围被划分成四个频宽类别：窄带、宽带、超宽带和全带。

 

窄带（narrowband）

普通电话所覆盖的频宽，从300Hz到3.4kHz，对应采样率6.8kHz。普通电话的采样率是8kHz，对应频宽4kHz，对于人声语音是足够的。

宽带（wideband）

从50Hz到7kH的频宽，对应采样率14khz，可以很好地捕捉和还原人声，然而对于音乐声还是不够的。这是在人声语音通话场景下的所谓高清语音。

超宽带（super-wideband）

从50Hz到14kHz，对应采样率28kHz，基本可以覆盖人声和音乐声，对于非专业音乐人的用户来说，不管是人声通话还是音乐直播，这样的频宽都是足够的。

 

全带（fullband）

从20Hz到20kHz，对应40kHz采样率，全面覆盖人类的听觉范围，能够满足音乐发烧友或者专业音乐人的需求。超过40Hz都可以称作全带语音。CD的采样率就是44.1kHz。

 

因此，窄带(narrowband)的音质是能满足游戏实时语音的通讯需求的。考虑到游戏实时语音和直播结合产生了一些新的玩法，比如说主播陪玩，或者游戏直播，对音质的要求相对较高。宽带(wideband)的音质能满足游戏加直播场景的需求。在这里，游戏语音的频宽更多地要根据游戏运营商的预算成本来确定，因为和频宽直接相关的是码率，码率最终也就是成本。

考量四大因素

为游戏量身订做实时游戏语音技术方案，要考量四大因素，从中找到平衡点。下图是对四大因素进行打分（1分最低，5分最高）而建立的雷达图：

 

成本

实时游戏语音数据的流量成本，一般由音频流的按月峰值带宽来表示。音频流的带宽，由每一路音频流的码率乘以音频流并发数目而获得。一路并发音频流就代表一个活跃的在线用户。对游戏运营商来说，音频流并发数目自然是越大越好。为了控制成本，只能从如何适当地降低每一路音频流的码率来下功夫。目的是在保证其它指标能接受的情况下，音频流的码率越低越好。

 

延迟时间

人声语音信息从一个用户经过系统和网络传达另外一个用户的单向延迟时间。一般来说，150毫秒以内的延迟时间，人耳是识别不了的，实时沟通十分流畅。400毫秒的延迟时间是一个临界点，超过这个临界点后，人耳就能感觉到比较明显的延迟。

笔者在即构科技参与过全球无死角网络覆盖测试，发现从中国一线城市到硅谷，RTT普遍就在160毫秒以上，单向就在80毫秒以上。 总的延迟时间还要加上编解码本身的算法延迟、全链条上的计算延迟、和网络损伤带来的传输延迟等。因此，在全球范围要获得150毫秒内的延迟是十分具有挑战性的。毕竟，RTT显示的单向基本延迟普遍也要80毫秒以上。

 

在游戏实时语音中，保持较低的通话延迟十分关键。想象一下，在MOBA或者FPS中，战斗正在火热朝天地进行着，一切都要用“说时迟那时快”来形容，队友之间的配合协调（比如说加血）慢了一两秒，带来的直接后果，轻则是殆误战机，重则是全军覆没。这是一个视用户体验为生命的游戏平台所不能忍受的。

 

音质

从客观的角度来看，语音的质量由采样率和码率等因素决定。一般来说，采样率越高音质越好；保持采样率不变，码率越高音质越好。从主观的角度来看，语音的质量由MOS主观评估方法来鉴定，也要通过人耳听感来衡量，毕竟最终是用户的耳朵来裁定音质好不好。

 

人耳对人声的音质的容忍度还是比较高的，而且不同的游戏和不同的场景对音质也有不同的要求。因此，可以根据不同的游戏场景来调整音质来让用户体验达到最优效果。在MMORPG、MOBA、和FPS等大型竞技类游戏中，并发数是海量的，总共带宽相当高。因此，要适当地降低音质，以其降低码率来降低成本。在棋牌和狼人杀等节奏比较慢（很多时候没人说话）且并发相对不高的休闲类游戏中，要适当地提高音质能提升用户体验。

 

和音质最紧密相关的因素是成本，其次是延迟和系统影响。一般来说，音质越好，码率也会越高，成本也就越高。因此，音质是一个可以微调的因素，用以达到适当的成本平衡点。

 

系统影响

实时游戏语音SDK被游戏系统进行端到端集成，在客户端和游戏系统共用系统资源，包括CPU和内存。在移动端，CPU和内存资源对游戏系统来说十分紧缺。因此，实时游戏语音SDK首先要做到尽量节约CPU和内存资源，再进一步的要做到和游戏和谐共生，那就是在游戏系统消耗资源比较多的时候，实时游戏语音SDK要降低码率和音质，优先保障语音的可用性；在游戏系统消耗资源比较少的时候，实时游戏语音SDK要能提高码率和音质，提高通话质量。语音编解码器的复杂度是影响移动终端CPU、内存和电量消耗的一个重要因素，语音编解码器的复杂度较低的话，消耗CPU、内存和电量也就相对少一些。

实时语音的模式

在游戏协同和沟通中，实时语音通话包括三种模式：

一对一私聊

社交关系比较紧密的两个游戏用户之间的一对一语音通话，通话的音质要高而且延迟要低。

 

多对多群聊

多个游戏用户组队语音开黑，每一个用户都参与到群聊中，通话的流畅性要高而且延迟要低。

 

多人群聊直播

类似多对多群聊，参与群聊的游戏用户充当指挥的角色，其它的游戏用户充当服从命令的角色，能收听群聊语音，而不能推送语音。另外，在游戏直播中，主播直接参与到游戏语音群聊中，同时把游戏的实况直播给不参与游戏的观众收听。在这种模式要求在群聊的少数几个人之间的通话流畅和低延迟，在观众侧保障通话的流畅就可以。

 

这三种实时游戏语音通话的模式对上述的四大因素：成本、延迟、音质和系统影响都有不同的侧重。除了要匹配这三种实时通话模式，还要匹配四种游戏语音场景。

游戏语音的场景

竞技游戏场景

包括MMORPG、MOBA、和FPS等类型的游戏，游戏的节奏极快，协同配合要求极高，系统资源也十分紧缺。实时游戏语音SDK要优先保障流畅性和低延迟，适当允许降低音质。为了满足这个场景的实时需求，推流和拉流都要经过核心媒体服务器。

 

休闲游戏场景

包括棋牌和狼人杀等类型的游戏，游戏的节奏比较慢，用户轮流说话，用户之间短暂的思考时间也是被接受的，系统资源占用率比较低。实时游戏语音SDK要优先保障音质和流畅性。在这种场景中，推流和拉流可以不经过核心媒体服务器，而直接走CDN网络。这种策略比较适合低成本的经济型方案。

 

大型国战场景

包括大型的MMORPG等类型的游戏，类似于竞技游戏场景。区别在于充当指挥角色的少数几个人需要进行快节奏的群聊，而其他的游戏用户处于收听状态。在这种场景中，首先群聊的几个人的音频流要经过核心媒体服务器，然后多路音频流被混和成一路流，接着转推到CDN网络，最后收听模式的游戏用户从CDN网络拉流收听。

选取音频编解码器

音频编解码器对游戏实时语音方案的四大关键因素有重要的影响。音频编码器的类型、属性和品质，决定了编出来的音频流的码率、算法延迟、频宽、和音质；音频编码器的算法复杂度决定了对CPU、内存、和电量的消耗程度。

 

因此，适合游戏实时语音方案的音频编解码器具备以下四个特点：

1）码率相对低，满足成本可控的要求，一般不要超过16kbps。一个sample用1bit就能编好，那么8kHz采样率（narrowband）对应8kbps的码率，16kHz采样率（wideband）对应16kbps的码率。码率的本质就是成本。

2）延迟时间要低到能满足互动需求，一般不要超过300毫秒。

3）算法复杂度要比较低，对系统CPU、内存和电量消耗少，对游戏系统影响要尽量低。

4）音质可以适当作出牺牲，以保障上面三个因素，8kHz采样率对人声场景是够用的，16kHz采样率可以提供高清语音。

 

下图列举一组主流的音频编解码器，展示了随着码率变化，音质相应变化的情况。这是基于编解码器听音测试的结果绘画出来的，对选取音频编解码器有参考意义。根据上面的分析并且参照下图，发现码率低于16kbps的低码率人声编解码器（speech codecs）包含：Opus（SILK）,Speex，AMR-NB，AMR-WB，和iLBC。

 

下图是另外一组主流的音频编解码器，展示了随着码率的变化，算法延迟时间相应变化的情况。根据上面的分析并且参照下图，发现算法延迟时间低于60毫秒，码率低于16kbps的人声编解码器（speech codecs）包含：Opus（SILK）、Speex(NB,WB)、G.729、和G.729.1。

 

综合上面的两个图，我们可以大致总结，比较适合实时游戏语音的音频编解码器包含Opus（SILK）、Speex（NB,WB）、AMR-NB、AMR-WB、iLBC、G.729、和G.729.1。

 

	码率	采样率	算法延迟
OPUS(SILK)	6-12,7-25， 8-30,12-40kbps	8，12， 16，24kHz	25ms
Speex	2.15–24.6 kbps (NB) 4–44.2 kbps (WB)	8, 16, 32, 48kHz	30 ms(NB) 34 ms (WB)
AMR-NB	4.75, 5.15, 5.90, 6.70, 7.40, 7.95, 10.20, 12.20 kbps	8kHz	25ms (20ms per frame plus 5ms look-ahead, 20ms for 12.2 kbps)
AMR-WB	6.60, 8.85, 12.65,14.25, 15.85, 18.25, 19.85, 23.05, 23.85 kbps	16kHz	25ms (20ms per frame plus 5ms look-ahead)
iLBC	13.33 kbps 15.20 kbps	8kHz	25 ms 40 ms
G.729	8kbps	8kHz	15 ms
G.729.1	8 kbps, 12–32 kbps	8kHz 16kHz	48.94ms
Codec2	0.7, 1.2, 1.3, 1.4, 1.6, 2.4, 3.2 kbps	8kHz	20–40 ms （额外增加的，超低码率）

 

上面都是为人声场景设计的低码率音频编解码器，具有码率低（16kbps以下），算法延迟低（大部分在40ms以下），和采样率在8kHz和16kHz之间的特点，都可供游戏实时语音方案选择。其中，有几个语音编解码器值得在这里稍作介绍：

 

Opus（SILK）

完全开源而且免费，包含了SILK、CELT、以及两者的混合模式，是目前最为兼容并包的音频编解码器。在处理窄带和宽带人声语音（speech）的时候，采用SILK;在处理超宽带和全带音乐声音（music）的时候，采用CELT。在人声和音乐声混合的场景中，甚至可以智能切换两个编解码器。WebRTC就采用了Opus作为语音编解码器。而SILK是Skype网络电话所用的语音编解码器。Opus真可谓是久经考验的名门精品。根据即构科技的测试结果，Opus虽然在音乐场景中表现并非首选，但是在人声场景中表现十分出色。

 

iLBC

完全开源而且免费的，由GIPS开发并被IETF标准化，曾经被QQ和Skype使用过，现在被WebRTC使用，是被世界顶级产品证明过的窄带实时语音编解码器。iLBC能够通过平滑降低语音质量的方式来处理IP网络丢包。由于iLBC的语音帧块之间是相互独立的，在丢帧出现的时候也不会导致错误蔓延，因此具有较强的抗丢包能力。在窄带应用环境中，iLBC具有延迟低，无断续或杂音的特点，通话效果可以和移动电话媲美。

Speex

免费的人声音频编解码器。因为Speex是为VoIP专门设计的，所以Speex对IP网络有很强的抗丢包能力。为了达到这个目的，Speex采用了CELP算法。笔者在上一周仔细研究了市场上狼人杀产品的游戏实时语音技术，就发现有厂商自研的方案采用了Speex。

 

Codec2

开源并且专利免费，码率超低的人声语音编解码器。码率在0.7 kbps至3.2 kbps。Codec2填补了开源编码器在5 kbps码率以下的空白。如果你觉得上面的语音编解码器码率都不够低，建议尝试一下Codec2。

 

在评估一个音频编解码器是否适合用于具体的游戏实时语音方案的时候，除了要评估上述的指标：码率、采样率、和算法延迟以外，还要参考MOS、VBR/CBR、和基础算法等。其中，MOS（Mean Opinion Score）是语音编解码器的主观评估指标。MOS是一个广为接受的有统计意义的主观听音指标。上面音视频编解码器的列表没有把它包含进去，是因为同一个编解码器，在不同码率下，表现出来的MOS值是会变化的。对一个音频编解码器给出一个固定的MOS值，反而会起误导的作用。另外，虽然MOS值已经是主观的听觉测试评估结果，但是音频工程师在选用音频编解码器的时候，还要以自己亲身的听感作为最终的依据。

 

下图是Nokia在2011年的时候对Opus、AMR、和G.722.1C等音频编解码器在无噪音和有噪音的环境里做的MOS语音测试的结果。我们可以从语音测试的结果看出：

1）MOS值会随着码率变化。固定的MOS值并没有绝对的参考意义。

2）在低码率情况下，AMR-NB和AMR-WB都表现相对出色。

 

 

 

没有任何一个音频编解码器可以适合任何应用场景。每一个音频编解码器都有自己的优势和劣势，都有适合它发挥作用的应用场景。在为游戏实时语音方案选取语音编解码器的时候，首先要梳理清楚该游戏场景的需求，然后根据需求去选取音频编解码器。

 

让我们回顾一下前面讨论过的游戏场景，分析如何针对游戏场景选取合适的语音编解码器。

 

竞技游戏场景

包括MMORPG、MOBA、和FPS等类型的游戏，游戏中组队的用户需要每时每刻十分高频地通话以协同作战，而且这种类型的游戏占用系统和网络资源很多。这种场景对游戏实时语音SDK的要求是码率低、延迟低、和消耗低，音质只要能保障沟通无阻就可以。因此，选取的音频编解码器要具备这些特点：码率低、算法延迟低、以及算法复杂度低。在这个前提下，再选取采样率较高和MOS值较高的音频编解码器。上述提到的Codec2、Speex、和AMR-NB都比较适合竞技游戏场景，建议对它们进行进一步测试对比。

 

有些休闲游戏的沟通节奏也相当快，比如说马东的米未传媒最近推出的饭局狼人杀，在杀人游戏环节允许用户插麦（插话），打破了传统狼人杀轮流发言而不允许插话的规则。在这种情况下，饭局狼人杀虽然是休闲游戏场景，但是也应该当做竞技游戏场景来处理。从技术的角度来说，选取的语音编解码器就要优先保障低延迟和流畅性，然后再考虑音质；另外，推拉流都要经过核心媒体服务器，以此获得比较低的延迟，插麦的效果才能保障。如果推流直接推送到CDN网络，插麦的延迟将会达到至少1到3秒，插话的体验就会无法接受。

 

休闲游戏场景

包括棋牌和狼人杀等类型的游戏，游戏中的用户交流的节奏不快，允许一到两秒的思考时间，而且这些游戏占用系统和网络资源也不多。这种游戏场景的社交属性比较强，社交关系好的游戏用户甚至会进行一对一私聊。休闲游戏场景对实时游戏语音SDK的要求是音质比较好、码率比较高；而延迟允许高一点，系统消耗也允许多一点。因此，选取的音频编解码器就要具备这些特点：采样率较高、码率较高、以及MOS值较高；在这个前提下，再选取算法延迟较低，和算法复杂度较低的音频编解码器。上述提到的Opus（SILK）、AMR-WB、Speex、和iLBC都比较适合休闲游戏场景，建议对它们进行进一步测试对比。

 

最近半年，休闲游戏的游戏实时语音技术出现了一些新的玩法：有些游戏平台在游戏实时语音中增加了实时视频。用户可以有选择性地在游戏实时视频中露脸，游戏平台也通过一些机制去鼓励用户多在视频中露脸。比如说奇虎360最近推出的萌萌狼人杀，又名花椒狼人杀（和花椒直播同样是奇虎360的产品），就在游戏用户轮到发言的时候，允许选择是否全屏展示视频。由于萌萌狼人杀采用了即构科技的游戏实时音视频方案，因此笔者比较清楚此类方案的技术细节。从技术的角度来说，增加了视频，必然会增加码率（带宽的开销）。在弱网的情况下，丢包率会骤然增加，音视频的质量也会相应下降，这时候要优先保障语音通话。具体地说，要优先保障语音的低延迟和流畅性，视频和音质可以稍微妥协。因此，在选用音频编解码器的时候，就要优先考虑码率低和延迟低的，甚至可以选用一套码率低的和一套采样率高的结合着使用，用以适应不同的应用场景和网络条件。

 

大型国战场景

包括大型的MMORPG等类型的游戏，充当指挥角色的一组游戏用户的网络沟通节奏其实和竞技游戏场景是类似的，选取音频编解码器的原则也类似。除了Codec2、Speex、和AMR-NB以外，其实Opus（SILK）的覆盖面很广，建议也测试对比一下。

 

 

经过几轮测试和对比下来，你很可能会发现，要结合使用一两个编解码器才能很好地满足某个游戏场景的需求。最终，我们要做的是寻找码率、延迟、复杂度、采样率、和MOS值这几个关键指标的平衡点。毕竟这几个指标和我们最开始讨论的四大要素：成本、延迟时间、系统影响、以及音质是紧密相关的。

 

要针对具体的游戏场景订造特定的解决方案，没有任何一套方案是放诸四海皆准的。要为具体的方案去配置特定的音视编解码器，和推流、拉流、以及混流策略。甚至有些时候，在同一套游戏实时语音解决方案中，要采用多个的音频编解码器来适应不同的业务场景或者网络状况的需求。

结语

因此，做游戏实时语音解决方案就是在游戏应用场景和技术方法之间做匹配。只有深入地理解游戏应用场景的需求，才能拿捏好如何选用语音编解码器，如何部署媒体服务器资源，如何配置CDN网络等，来打磨出一套符合游戏应用场景需求的实时语音解决方案。