短视频直播系统开发需要解决的问题和解决方式

这篇文章是写音视频云服务的，短视频直播系统开发恰好需要相关的只是点，转载过来与君共赏

说到音视频云服务，大多数人可能联想到的是网络直播应用场景，实际上，硬件对音视频云服务的需求也在逐渐提升。而这样的市场需求也推动了整个行业的发展，目前，阿里云、腾讯云和网易云、即构科技等巨头都已经入局，并推动了短视频直播系统开发市场。

一、 要做好短视频直播软件开发，需要解决的问题：

1)延迟比较大，做不到连麦互动多人对讲的效果。

2)无法全面兼容众多安卓机型，长尾用户群体无法全面覆盖。

3)硬件场景声音环境复杂，噪音抑制和回声消除的效果不好。

4)视频画面卡顿不流畅，观看效果不好。

5)如果使用基于udp的私有协议，无法被CDN网络支持;如果使用基于RTMP的标准协议，无法获得理想的低延迟。

6)无法支撑海量用户并发，或者在海量并发情况下，效果不稳定。

7)多个人同时说话，甚至出现抢话(所谓双讲)的情况下，语音效果不好。

做好短视频直播系统开发的技术难点是什么?

直播和短视频需要让用户在任何一个地方任何一个时候可以听见看见。由此可见，短视频直播系统开发需要的音视频流需要对音视频数据进行处理和传输。

1、 音视频通信的整个流程包括：
采集，编码，推流，转码，存储，拉流，解码，渲染(播放)。每一个环节都会有很多的坑，都需要投入很多人力和时间去填平这些坑，都需要时间去试错。因此，要做好音视频，除了靠技术的积累还要靠多年的经验。

2、 采集和渲染：
音视频信息是从通话的发起端，进行语音和视频的采集;在通话的接收端进行语音和视频的渲染。而采集和渲染两个环节会涉及到具体硬件的音视频设备的性能。需要注意的是，采集和渲染都会用到具体硬件平台的接口，这和具体硬件设备的接口、设计和性能等密不可分。因此，在系统设计阶段，就要考虑硬件设备的兼容性和跨平台。

3、 编码和解码：
编解码环节会涉及到具体硬件芯片的处理能力。我们可以将其分为两类：一类是采用硬编硬解，另一种是采用软编软解，二者各有各的优缺点。

4、编解码
硬编硬解要用到GPU的处理能力，优点是效率高，速度快，分担CPU的压力，减少CPU发热;缺点就是不同的硬件平台的芯片性能和接口参数不一样，要进行适配。软编软解不使用GPU，而使用的是CPU的计算能力，优点是对各个硬件平台的兼容性好，缺点就是计算的压力都放在CPU上了，速度慢，效率低，而且CPU会发热。需要注意的是，有些设备CPU和摄像头离得比较近，CPU发热可能会导致摄像头采集的时候丢帧。

除了采集、渲染、编码解码这几个终端环节以外，其它环节的和硬件平台不相关，属于后端的范畴，和目前在娱乐直播行业、在线教育行业、游戏语音行业、大规模游戏语音直播行业的方案都没有差异。下面对后端的原理简单阐述。

5、 推流：
是发起音视频通讯的智能终端设备把音视频流推送到音视频服务器集(注：音视频服务器集群是一个统称，里面比较复杂，包括音视频流服务器，信令调度服务器和混流服务器等，可以简单的理解为云端)。推流是能否做到低延迟的关键。智能终端所在的环境十分的复杂，要适应这些复杂的环境，要做很多工作。例如，一般情况下上下行的网络不对称，上行网络远远小于下行网络，而且用户的设备质量参错不齐，所在区域的接入点服务质量良莠不齐。推流可以分为两步：1)选路，选择一条最优的路径;然后2)推流，在该路径上做到最优。在服务器集群上的处理包括混流(如果需要)和存储等，然后把音视频流转推到CDN网络去。

6、 拉流：
是需要观看的用户拉去音视频流到终端设备观看。拉流的用户分为两类，一类是普通的观众，一类是参与到多人互动对讲中的用户。相对来说，普通的观众对低延迟要求不高，只要求流畅和高质量，所以可以使用CDN网络来均衡质量和成本。观众端从就近的CDN网络进行拉流，在智能终端进行解码和播放。使用的协议是RTMP, HLS或者HTTP-FLV协议，多种协议可以适配不同的环境。有些智能硬件场景是没有普通观众的，那么就只有参与音视频互动对讲的用户了。对于进行互动对讲的核心的参与者，音视频流是不经过CDN网络的。各个参与者是直接从音视频流媒体服务器上拉流来的播放。音视频流媒体服务器的质量相对比较好，网络资源也比较好，能够提供低延迟和高质量的音视频服务。

这是一个典型的音视频直播云服务的系统架构，同样可以应用到智能硬件的场景中，比如说无人机航拍直播。举个例子，即构科技有个客户是做房地产销售的，他们组织几个房地产专家进行连麦互动谈话，讨论楼盘的各种情况，并对实况进行直播，场外有上万的观众在线观看直播。推流端包括几个身处各地的房地产专家还有几个在楼盘现场航拍的无人机上的摄像头，拉流端就是观看直播的观众和各位房地产专家。从系统架构的角度来说，房地产专家的音视频通讯是在音视频流媒体服务器集群上完成的，没有转推流到CDN;而观看直播的观众，就会从CDN网络上拉流。

关于开发上的难点，已经包含在上面我们所解决的问题列表里。这里重复了一下：

1）延迟比较大，做不到连麦互动多人对讲的效果。

2）无法全面兼容众多安卓机型，长尾用户群体无法全面覆盖。

3）硬件场景声音环境复杂，噪音抑制和回声消除的效果不好。除了开发上的难点，还有运维上的难点：

4）对系统内部运作可见度不高，不可管控，出现紧急问题的时候很难快速定位。

5）当紧急问题出在网络运营商，基础云商，或者CDN网络那边的时候，无法及时得到事故通知，也无法得到及时而深度的配合。

6）在一些边远的地理区域，网络覆盖不足，用户体验比较差或者不稳定。

7）来自不同的网络的用户得到的体验不一样，造成某些网络的用户体验比较差。运维上的难点更多的偏向于经验的积累，只有踩过足够多的坑，只有经历过长时间的试错，才能够把系统打磨得比较顺溜。

怎么获得低延迟、而保证高音质和高画质?

低延迟是一个比较难的技术点，这也是即构科技解决得比较好的一个问题。目前，使用即构科技的音视频直播SDK，参与连麦互动直播各方的延迟达到400毫秒，观众端的延迟达到1秒左右。这个低延迟指标在市场上是十分有竞争力的。举个例子，花椒直播(奇虎360投资的企业，日活超过500万)采用了即构科技的直播技术方案，原因是即构科技的视频直播SDK延迟极低，能做到移动端六路连麦互动，能让明星主播进行“同框”互动直播。

要降低延迟也是要从采集，编码，推流，拉流，解码和渲染整个链接来解决的，可以从下面几个点进行探索：

1)采集、视频处理和编码尽量减少内存多处拷贝，减少CPU和GPU处理多次切换;

2)解码、视频后处理和渲染也是类似的方式;

3)另外就是推拉流的链路上的优化，包括就近接入，和减少多层级server的转发等。这些都要根据实际用户策略来做。

关于高音质和高画质怎么保证，可以从以下几点来探索：

1)音频的数据量比较小，对带宽的要求比较低，一般不会限制音频，要优先保证音频数据可以发送。毕竟，在极端差网的情况下，即使视频不好，只要音频清晰流畅，互动沟通还是可以继续的。

2)为了获得低延迟同时保证视频的质量，要平衡流畅和清晰度，现在通常采用VBR或者CBR来处理。在保证画面质量不至于太差的情况下，可以选择性性地丢帧。这样可以避免推流端因为TCP拥塞导致于推流质量越来越差，否则除了引起卡顿也会引起画面质量下降严重。在网络确实太差的情况下，通常为了保证视频流畅，可以适当地降低推流码率，这样画面质量会有不可避免的下降。通常的做法是设置一个极限值，避免视频质量太低无法观看。

怎么优化音视频云服务对CPU和带宽资源耗费?

CPU资源

使用智能硬件设备的芯片进行音视频的编码解码的时候会面临两个选择：硬编硬解，还是软编软解。要降低对CPU的消耗，就要充分的利用GPU的能力。使用GPU就要进行硬编硬解，优点是速度快，效率高，CPU的占用低，缺点对兼容性有要求，需要对具体硬件平台进行深度兼容，才能做好硬编硬解。

带宽资源

要解决带宽资源消耗的问题，可以从两个角度入手：码率自适应，和云端混流。

码率自适应，就是让音视频流的码率能够自动适应复杂的网络环境，比如说网络抖动。我们都知道，在中国，用户端的上下行网络带宽是不对称的。比如说，下行如果是100Mbps，那么对应的上行就是1Mbps, 这样上行就成了瓶颈，下行反而问题不大。因此，要确保推流成功而且质量好，那么就要利用好上行的网络带宽。推流端要能够做到根据各种维度的因素，包括个体历史数据，群体历史数据，网络探测数据等等，去分析和预测网络的情况，从而决定推流应该采用多大的码率。关键点就是要找出在目前上行带宽的情况下小于上行带宽的最大码率。

云端混流，就是把多路的音视频流在服务器集群里面混合成一路流，然后转推到CDN去，让观众拉单流来观看。这样可以节省一部分带宽成本。拉流端拉流的时候有两个选择，一个是把所有推流端的音视频流单独拉下来播放，另一个就是把在云端混合好的单一一路流拉下来播放。如果采用不混流的方案，优点是拉流端可以灵活地操控多路流，比如说让画中画中的画面灵活对调， 缺点就是多占用了网络带宽。如果采用混流的方案，优点就是拉流端只需要拉一路流，可以大大的节省从流媒体服务器到CDN网络和CDN网络到拉流端所占的网络带宽，缺点就是多路音视频经过混流以后，画面的布局就固定了，在拉流端无法再进行灵活操控了。

评价音视频通信质量好坏的标准

评判一个音视频云服务质量好不好，要看技术指标，也要看非技术指标。毕竟这是技术服务，是技术也是服务。

技术上的指标包括但是不限于：1)低延迟;2)流畅性;3)回声消除;4)噪音抑制;5)跨平台;6)全终端兼容;7)海量用户并发;8)无感知扩容能力。

低延迟：这个很重要，但是到了一定临界值以后，就不是最重要的指标了。一般来说低于800毫秒的延迟，就能够做到多人实时连麦互动，做到比较好的对讲，比较好的高频互动;高于800毫秒的延迟，就只能做监控，只能做单向直播了，这样的效果和点播的差别不是很大，是做不到连麦互动或者多人实时对讲的。

流畅性：这个影响用户体验的关键指标。但低延迟和流畅性实际上是矛盾的，要获得最低的延迟，最好就是让缓冲队列尽量地短;但是要做到流畅，缓冲队列就要有一定的长度，才能够抹平网络抖动带来的影响。所以，我们要在低延迟和流畅性这对矛盾的指标上找到一个平衡点。

回声消除和噪音抑制能力：这两项最能考验音视频技术能力的水平，这也是一流的音视频直播云服务区分其它竞品的利器。在选择方案的时候，要看能否做到没有回声，没有啸叫(不带耳机的哦)。还要看能否有效抑制环境噪音，声音清晰而且通透。有创业团队找到我说，他们团队的技术很厉害，自己花了大半年就把音视频通讯系统做出来的，就是这两项怎么做都效果不理想。其实音频比视频要难，音频里面这两个点是最难的，不是那么容易做得好的。

为了支持短视频直播软件开发，音视频直播云服务要能够做到以下三点：

1. 在创业早期，要能够以较低成本，较快的速度，让早期的产品集成音视频直播SDK。因为早期团队缺乏资金，但是又要求快。因此音视频直播SDK必须是简单易用的，而且是端对端集成的。

2. 在创业中期，要能够快速而且无感知的扩容，不能影响到生产环境，不能对用户体验造成损害。因此，音视频直播云服务必须要能够做到无感知地水平扩容，在云端通过配置增加网络，基础云和CDN等资源。

3. 在创业早期，要能够以较低成本，较快的速度，让早期的产品集成音视频直播SDK。因为早期团队缺乏资金，但是又要求快。因此音视频直播SDK必须是简单易用的，而且是端对端集成的。

4. 在创业中期，要能够快速而且无感知的扩容，不能影响到生产环境，不能对用户体验造成损害。因此，音视频直播云服务必须要能够做到无感知地水平扩容，在云端通过配置增加网络，基础云和CDN等资源。

3)在创业后期，要能够支持海量用户并发，确保服务持续而且稳定。因此音视频云服务的架构要能够支持千万级别的海量用户并发，技术团队要有多年海量运营的经验，和运营商的基建要能够深度的结合才行。关于未来

请允许我斗胆判断一下未来，未来音视频直播云服务可能有两个趋势：

1)公共事业服务化：未来会更加趋向于接受由专业的人做专业的事情，音视频直播云服务会成为像自来水一样广泛而且中立的公共事业服务，就像今天的基础云服务一样，谁都可以很便利很放心地使用，没有人担心安全性，也没有必要重复发明轮子。

2)成为互联网主流互动方式： 音视频的流量占网络流量的比例越来越大，VR/AR音视频的信息量还会有数倍的提升，可以预测音视频通讯成为网络流量的主要贡献者。从用户的角度来说，要能听见看见，音视频互动是最直观最自然的互动方式。从商业的角度来说，网络运营商，基础云商还有CDN网络，都会特别喜欢这个趋势，毕竟音视频的流量比文本的流量大的多，流量多起来了，就意味着更大规模的基建，更大规模的收入流水。因此，网络运营商、基础云商、CDN网络和音视频直播云服务商都会把音视频技术作为标配能力。毕竟，控制主要流量的来源，就控制了未来发展的命脉。

当我们在展望未来，未来已经变成了现在。要能听见看见，这个自然而简单的需求，会让音视频直播云服务在未来跟随着智能终端深入到互联网生活的每一个环节中去，深刻地改变人们互动沟通的方式。