说到音视频云服务，大多数人可能联想到的是网络直播应用场景，实际上，硬件对音视频云服务的需求也在逐渐提升。而这样的市场需求也推动了整个行业的发展，目前，阿里云、腾讯云和网易云等巨头都已入局，除此之外还有即构科技这样的新兴企业加入了这一竞争行列。
大家都知道，音视频云服务降低了硬件接入音视频的门槛，但是，在使用这一服务的过程中难免踩坑，这是音视频云服务提供商以及硬件团队都格外重视的，但问题是具体有哪些坑以及如何避免呢？本期硬创公开课将为您一一解答。
嘉宾介绍
冼牛，即构科技市场运营总监，资深技术人，市场营销新兵，客串投资顾问，骨灰级游泳者。北京邮电大学计算机硕士，中国香港大学工商管理硕士，一直秉承人丑应该多读书的理念，读书不断。2008年起旅居中国香港至今，2015年回流深圳南山创业，服务过爱立信中国香港，摩根大通中国香港，和分期乐集团等老东家。
以下内容整理自本期公开课：
音视频直播云服务的硬件应用场景
实际上，音视频直播云服务的硬件应用场景并不少：车联网，智能家居，远程医疗和户外活动等。这是正在发展的场景，还有很多潜在的场景，会在未来几年逐渐展现。智能终端对音视频云直播服务的需求在不断增加。举个栗子，目前在国外玩得比较热的户外直播、无人机直播，都是智能硬件的一些典型应用场景。
通俗点说，音视频直播云解决的最终极问题就是：让你听见，看见，就像在面前一样。然而，这个简简单单的问题，在复杂的网络环境，硬件平台，操作系统，海量并发运维等等因素综合加在一起，就变成了一个十分复杂的问题。
以即构科技为例，在做音视频直播云服务的过程中针对智能终端解决了以下问题：
1）延迟比较大，做不到连麦互动多人对讲的效果。 2）无法全面兼容众多安卓机型，长尾用户群体无法全面覆盖。 3）硬件场景声音环境复杂，噪音抑制和回声消除的效果不好。 4）视频画面卡顿不流畅，观看效果不好。 5）如果使用基于udp的私有协议，无法被CDN网络支持；如果使用基于RTMP的标准协议，无法获得理想的低延迟。 6）无法支撑海量用户并发，或者在海量并发情况下，效果不稳定。 7）多个人同时说话，甚至出现抢话（所谓双讲）的情况下，语音效果不好。 8）对系统内部运作可见度不高，不可管控，出现紧急问题的时候很难快速定位。
音视频通信的原理以及技术难点是什么？
上文提到，音视频直播云服务要做的事情就是让用户在任何一个地方任何一个时候可以听见看见。由此可见，核心的问题就是对音视频数据的处理和传输。
音视频通信的整个流程包括：采集，编码，推流，转码，存储，拉流，解码，渲染（播放）。每一个环节都会有很多的坑，都需要投入很多人力和时间去填平这些坑，都需要时间去试错。因此，要做好音视频，除了靠技术的积累还要靠多年的经验。
采集和渲染：音视频信息是从通话的发起端，进行语音和视频的采集；在通话的接收端进行语音和视频的渲染。而采集和渲染两个环节会涉及到具体硬件的音视频设备的性能。需要注意的是，采集和渲染都会用到具体硬件平台的接口，这和具体硬件设备的接口、设计和性能等密不可分。因此，在系统设计阶段，就要考虑硬件设备的兼容性和跨平台。
编码和解码：编解码环节会涉及到具体硬件芯片的处理能力。我们可以将其分为两类：一类是采用硬编硬解，另一种是采用软编软解，二者各有各的优缺点。
硬编硬解要用到GPU的处理能力，优点是效率高，速度快，分担CPU的压力，减少CPU发热；缺点就是不同的硬件平台的芯片性能和接口参数不一样，要进行适配。软编软解不使用GPU，而使用的是CPU的计算能力，优点是对各个硬件平台的兼容性好，缺点就是计算的压力都放在CPU上了，速度慢，效率低，而且CPU会发热。需要注意的是，有些设备CPU和摄像头离得比较近，CPU发热可能会导致摄像头采集的时候丢帧。
除了采集、渲染、编码解码这几个终端环节以外，其它环节的和硬件平台不相关，属于后端的范畴，和目前在娱乐直播行业、在线教育行业、游戏语音行业、大规模游戏语音直播行业的方案都没有差异。下面对后端的原理简单阐述。
推流是发起音视频通讯的智能终端设备把音视频流推送到音视频服务器集（注：音视频服务器集群是一个统称，里面比较复杂，包括音视频流服务器，信令调度服务器和混流服务器等，可以简单的理解为云端）。推流是能否做到低延迟的关键。智能终端所在的环境十分的复杂，要适应这些复杂的环境，要做很多工作。例如，一般情况下上下行的网络不对称，上行网络远远小于下行网络，而且用户的设备质量参错不齐，所在区域的接入点服务质量良莠不齐。推流可以分为两步：1）选路，选择一条最优的路径；然后2）推流，在该路径上做到最优。在服务器集群上的处理包括混流（如果需要）和存储等，然后把音视频流转推到CDN网络去。
拉流的用户分为两类，一类是普通的观众，一类是参与到多人互动对讲中的用户。相对来说，普通的观众对低延迟要求不高，只要求流畅和高质量，所以可以使用CDN网络来均衡质量和成本。观众端从就近的CDN网络进行拉流，在智能终端进行解码和播放。使用的协议是RTMP, HLS或者HTTP-FLV协议，多种协议可以适配不同的环境。有些智能硬件场景是没有普通观众的，那么就只有参与音视频互动对讲的用户了。对于进行互动对讲的核心的参与者，音视频流是不经过CDN网络的。各个参与者是直接从音视频流媒体服务器上拉流来的播放。音视频流媒体服务器的质量相对比较好，网络资源也比较好，能够提供低延迟和高质量的音视频服务。
这是一个典型的音视频直播云服务的系统架构，同样可以应用到智能硬件的场景中。比如说无人机航拍直播。举个例子，即构科技有个客户是做房地产销售的，他们组织几个房地产专家进行连麦互动谈话，讨论楼盘的各种情况，并对实况进行直播，场外有上万的观众在线观看直播。推流端包括几个身处各地的房地产专家还有几个在楼盘现场航拍的无人机上的摄像头，拉流端就是观看直播的观众和各位房地产专家。从系统架构的角度来说，房地产专家的音视频通讯是在音视频流媒体服务器集群上完成的，没有转推流到CDN；而观看直播的观众，就会从CDN网络上拉流。
关于开发上的难点，已经包含在上面我们所解决的问题列表里。这里重复了一下：
1）延迟比较大，做不到连麦互动多人对讲的效果。 2）无法全面兼容众多安卓机型，长尾用户群体无法全面覆盖。 3）硬件场景声音环境复杂，噪音抑制和回声消除的效果不好。
除了开发上的难点，还有运维上的难点：
1） 对系统内部运作可见度不高，不可管控，出现紧急问题的时候很难快速定位。 2）当紧急问题出在网络运营商，基础云商，或者CDN网络那边的时候，无法及时得到事故通知，也无法得到及时而深度的配合。 3）在一些边远的地理区域，网络覆盖不足，用户体验比较差或者不稳定。 4）来自不同的网络的用户得到的体验不一样，造成某些网络的用户体验比较差。
运维上的难点更多的偏向于经验的积累，只有踩过足够多的坑，只有经历过长时间的试错，才能够把系统打磨得比较顺溜。
低延迟、高音质和高画质怎么保证？
低延迟是一个比较难的技术点，这也是即构科技解决得比较好的一个问题。目前，使用即构科技的音视频直播SDK，参与连麦互动直播各方的延迟达到400毫秒，观众端的延迟达到1秒左右。这个低延迟指标在市场上是十分有竞争力的。举个例子，花椒直播（奇虎360投资的企业，日活超过500万）采用了即构科技的直播技术方案，原因是即构科技的视频直播SDK延迟极低，能做到移动端六路连麦互动，能让明星主播进行“同框”互动直播。
要降低延迟也是要从采集，编码，推流，拉流，解码和渲染整个链接来解决的，可以从下面几个点进行探索：
采集、视频处理和编码尽量减少内存多处拷贝，减少CPU和GPU处理多次切换；
解码、视频后处理和渲染也是类似的方式；
另外就是推拉流的链路上的优化，包括就近接入，和减少多层级server的转发等。这些都要根据实际用户策略来做。
关于高音质和高画质怎么保证，可以从以下几点来探索：
1） 音频的数据量比较小，对带宽的要求比较低，一般不会限制音频，要优先保证音频数据可以发送。毕竟，在极端差网的情况下，即使视频不好，只要音频清晰流畅，互动沟通还是可以继续的。
2） 为了获得低延迟同时保证视频的质量，要平衡流畅和清晰度，现在通常采用VBR或者CBR来处理。在保证画面质量不至于太差的情况下，可以选择性性地丢帧。这样可以避免推流端因为TCP拥塞导致于推流质量越来越差，否则除了引起卡顿也会引起画面质量下降严重。在网络确实太差的情况下，通常为了保证视频流畅，可以适当地降低推流码率，这样画面质量会有不可避免的下降。通常的做法是设置一个极限值，避免视频质量太低无法观看。
怎么优化音视频云服务对CPU和带宽资源耗费？
CPU资源
使用智能硬件设备的芯片进行音视频的编码解码的时候会面临两个选择：硬编硬解，还是软编软解。要降低对CPU的消耗，就要充分的利用GPU的能力。使用GPU就要进行硬编硬解，优点是速度快，效率高，CPU的占用低，缺点对兼容性有要求，需要对具体硬件平台进行深度兼容，才能做好硬编硬解。
要解决带宽资源消耗的问题，可以从两个角度入手：码率自适应，和云端混流。
码率自适应，就是让音视频流的码率能够自动适应复杂的网络环境，比如说网络抖动。我们都知道，在中国，用户端的上下行网络带宽是不对称的。比如说，下行如果是100Mbps，那么对应的上行就是1Mbps, 这样上行就成了瓶颈，下行反而问题不大。因此，要确保推流成功而且质量好，那么就要利用好上行的网络带宽。推流端要能够做到根据各种维度的因素，包括个体历史数据，群体历史数据，网络探测数据等等，去分析和预测网络的情况，从而决定推流应该采用多大的码率。关键点就是要找出在目前上行带宽的情况下小于上行带宽的最大码率。
云端混流，就是把多路的音视频流在服务器集群里面混合成一路流，然后转推到CDN去，让观众拉单流来观看。这样可以节省一部分带宽成本。拉流端拉流的时候有两个选择，一个是把所有推流端的音视频流单独拉下来播放，另一个就是把在云端混合好的单一一路流拉下来播放。如果采用不混流的方案，优点是拉流端可以灵活地操控多路流，比如说让画中画中的画面灵活对调， 缺点就是多占用了网络带宽。如果采用混流的方案，优点就是拉流端只需要拉一路流，可以大大的节省从流媒体服务器到CDN网络和CDN网络到拉流端所占的网络带宽，缺点就是多路音视频经过混流以后，画面的布局就固定了，在拉流端无法再进行灵活操控了。
音视频SDK怎么适配智能终端，如何做到跨平台和广泛兼容？
目前智能终端主流的操作系统包括iOS和安卓。iOS是苹果的智能终端操作系统，苹果的机型数目有限，而且设计和质量都比较好，要适配苹果的设备和iOS问题不大。比较难的是如何适配安卓操作系统。安卓是谷歌的开源智能终端操作系统，正因为是开源的，所以各个厂商可以做各种大尺度的裁剪和修改。特别是在中国国内市场，安卓机型十分繁多，而且架构设计，硬件质量良莠不齐；安卓操作系统也做了很多的裁剪和修改。我这里举的安卓智能手机的例子，其实也适用于采用了安卓操作系统的其它智能终端，比如说无人机或者智能电视。因此，我们说要全面兼容各种智能终端，其实说的就是如何全面兼容安卓操作系统和各种各样的智能终端硬件平台。
众所周知，安卓是开源的操作系统，底层提供c接口，上层提供java接口。国内的厂商在对安卓系统进行裁剪和修改的时候，为了提高效率和降低成本，大部分都是直接调用java接口进行修改的。
在即构科技创业初期，我们也考虑过调用java接口进行优化，来开发音视频引擎和其它各种适配工作，后来发现行不通。这条路虽然看起来节省成本而且提高效率，但是损失的是兼容性和稳定性。一套代码无法在各种各样的安卓平台上稳定运行，反而是提高了成本和降低了效率。于是我们采用比较笨，也是最基础的方法，从最底层做起，尽量地调用c接口，去做深层优化，去实现音视频终端引擎。这个过程虽然十分痛苦十分的累，但是最终一套代码可以在各种各样的平台上使用，终端音视频引擎的稳定性和兼容性也是真心的好，因此我们认为十分值得。所以，在兼容全终端、做到跨平台这一点上面，建议大家用比较笨的基础的方法，从最底层进行优化，这样才能保证兼容性和稳定性。
由于即构科技的音视频SDK是进行端对端集成的，而后端是完全解耦的，所以只要智能终端实现了全面的兼容性，后端就完全没有兼容性问题了。现在，即构科技的音视频直播方案，能够跨越iOS、安卓、WP和H5四个平台，能够兼容PC、各种手机和PAD三种终端类型，用的就是直接从底层深度优化这个笨办法。
另外一点也值得提一下，在拉流端，为了兼容和适配观众端各种各样的平台，我们提供了多种协议进行拉流：RTMP, HLS, HTTP-FLV。用RTMP或者HTTP-FLV拉流可以用即构的SDK（APP）或者Adobe Flash Player上观看，用HLS拉流可以在H5上观看。这样可以确保全面覆盖各种各样的终端用户。
评价音视频通信质量好坏的标准
评判一个音视频云服务质量好不好，要看技术指标，也要看非技术指标。毕竟这是技术服务，是技术也是服务。
技术上的指标包括但是不限于：1）低延迟；2）流畅性；3）回声消除；4）噪音抑制；5）跨平台；6）全终端兼容；7）海量用户并发；8）无感知扩容能力。
低延迟，这个很重要，但是到了一定临界值以后，就不是最重要的指标了。一般来说低于800毫秒的延迟，就能够做到多人实时连麦互动，做到比较好的对讲，比较好的高频互动；高于800毫秒的延迟，就只能做监控，只能做单向直播了，这样的效果和点播的差别不是很大，是做不到连麦互动或者多人实时对讲的。
流畅性，这个影响用户体验的关键指标。但低延迟和流畅性实际上是矛盾的，要获得最低的延迟，最好就是让缓冲队列尽量地短；但是要做到流畅，缓冲队列就要有一定的长度，才能够抹平网络抖动带来的影响。所以，我们要在低延迟和流畅性这对矛盾的指标上找到一个平衡点。
回声消除和噪音抑制能力，这两项最能考验音视频技术能力的水平，这也是一流的音视频直播云服务区分其它竞品的利器。在选择方案的时候，要看能否做到没有回声，没有啸叫（不带耳机的哦）。还要看能否有效抑制环境噪音，声音清晰而且通透。有创业团队找到我说，他们团队的技术很厉害，自己花了大半年就把音视频通讯系统做出来的，就是这两项怎么做都效果不理想。其实音频比视频要难，音频里面这两个点是最难的，不是那么容易做得好的。
跨平台和终端兼容性，上文有介绍，就不再赘述了。
海量用户并发，这个十分考验海量并发运维能力。C端的业务，靠的是海量的用户取胜。音视频技术很多团队自己就能做出来，demo跑的时候挺好，一对一效果不错，但是用户量一上来就开始不稳定，就要不断地进行重构和迭代，就要不断地经历服务中断。
无感知扩容能力，这对创业团队来说很重要。创业团队处于业务的快速扩展期，往往几个月用户就要成倍增长。为了扩容可能要进行版本迭代升级，甚至重构，这样很可能会终端服务，极其影响用户体验。能否做到无感知扩容十分考验一个音视频云服务商的运营经验和网络资源。这里就不仅仅是技术了，更多的是要考验是能和网络运营商，技术云商，CDN网络合作深度。这些运营经验都要靠不断试错，靠多年运营积累总结出来的。
看完上述技术指标后，让我们看看非技术指标：
技术服务的深度，要看知道技术支持的是核心技术团队还是普通客服团队。如果核心技术团队能够主导SDK集成接入和后期的运维支持，他们能够帮你解决深度的技术问题，帮你提供经验和建议。如果只是客服团队经过简单培训上岗，对着FAQ文档回答你的问题，那样的服务是远远不够的。
运维支持的能力和反应速度，这方面要看一手硬的和一手软的。所谓硬的，就是看有没有健全而强大的后台监控系统，能否全面的看到每一路流，每个节点的各项技术指标，实时监控状态，一出问题就可以快速定位。所谓软的，就是要看这个音视频云服务团队的市场口碑和自我定位，看它是不是能够对大小客户都一视同仁，能够积极快速反应，积极处理问题，能够踏实地提供服务。
和网络运营商以及基础云商合作的深度，这要看和基础云商，CDN网络的关系，能否让对方配合做一些深度的适配，能否及时地得到事故通知，能否让对方帮忙解决问题等。
这是都是企业在接入音视频云服务的时候该十分注意的问题。毕竟，选择一个云服务可能因为它技术指标好，抛弃一个云服务往往可能因为它非技术指标不好。
智能终端的创业公司会快速增长扩容，到后期会要求支持海量用户并发，音视频直播云服务如何满足这样的要求？
实际上，这是很多创业企业的痛点。这些创业型的团队直接面对C端的用户。刚刚启动的时候，用户很少，可能只有几百个； 但是后面几个月可能会成倍的增长，达到数十万甚至上百万个用户。面向C端的用户系统在扩容来跟上用户量增长的过程中，可能会出现扩容周期过长，系统不稳定，甚至服务中断等问题。
即构科技从两个方面来解决这个问题：
1）服务端架构能够进行灵活水平扩容。在信令层面，在架构设计的时候，我们就按照用户的预期增长，做好了相应的设计，允许水平扩展。在保证多媒体服务器集群业务侧无状态的前提下，结合我们的智能调度系统，保证调度给用户的资源是足够的。这个架构支持我们能够根据客户的容量需求，水平的把网络资源十分灵活地铺开，能够做到让C端的用户感觉不到任何中断 。
2）有丰富网络节点资源来做到无感知的扩容。网络节点资源的支持也十分的重要，即构科技和一线的网络运营商进行深度对接，储备足够的网络节点资源来满足创业企业客户群不断扩容的需求。
智能终端的创业公司也是面对C端用户，用户量发展特别快，靠速度取胜。 C端用户并发的用户数到稳定阶段会十分庞大。举个例子，智能终端应用于汽车，也就是所谓的车联网，具体的应用是音频直播，也就是现在广播电台的替代产品。这一类的产品，最后能存活下来并且发展壮大的靠的是速度和用户规模。
因此，为了支持创业企业快速发展，音视频直播云服务要能够做到以下三点：
1) 在创业早期，要能够以较低成本，较快的速度，让早期的产品集成音视频直播SDK。因为早期团队缺乏资金，但是又要求快。因此音视频直播SDK必须是简单易用的，而且是端对端集成的。 2) 在创业中期，要能够快速而且无感知的扩容，不能影响到生产环境，不能对用户体验造成损害。因此，音视频直播云服务必须要能够做到无感知地水平扩容，在云端通过配置增加网络，基础云和CDN等资源。 3）在创业后期，要能够支持海量用户并发，确保服务持续而且稳定。因此音视频云服务的架构要能够支持千万级别的海量用户并发，技术团队要有多年海量运营的经验，和运营商的基建要能够深度的结合才行。
关于未来
请允许我斗胆判断一下未来，未来音视频直播云服务可能有两个趋势：
1）公共事业服务化：未来会更加趋向于接受由专业的人做专业的事情，音视频直播云服务会成为像自来水一样广泛而且中立的公共事业服务，就像今天的基础云服务一样，谁都可以很便利很放心地使用，没有人担心安全性，也没有必要重复发明轮子。
2）成为互联网主流互动方式： 音视频的流量占网络流量的比例越来越大，VR/AR音视频的信息量还会有数倍的提升，可以预测音视频通讯成为网络流量的主要贡献者。从用户的角度来说，要能听见看见，音视频互动是最直观最自然的互动方式。从商业的角度来说，网络运营商，基础云商还有CDN网络，都会特别喜欢这个趋势，毕竟音视频的流量比文本的流量大的多，流量多起来了，就意味着更大规模的基建，更大规模的收入流水。因此，网络运营商、基础云商、CDN网络和音视频直播云服务商都会把音视频技术作为标配能力。毕竟，控制主要流量的来源，就控制了未来发展的命脉。
当我们在展望未来，未来已经变成了现在。要能听见看见，这个自然而简单的需求，会让音视频直播云服务在未来跟随着智能终端深入到互联网生活的每一个环节中去，深刻地改变人们互动沟通的方式。
