1.低延迟
要想保证低延迟，前端和后端整个链条一定要做的非常严谨。像前端的一些编码算法或者是丢帧策略等都要做好。此外，不同的业务场景之间编码器的选择也会有所不同，从而也会带来不同程度上的编码延迟，所以不同的业务场景能够达到的延迟程度也是不一样的。还有就是对于推拉流网络的选择，大部分的解决方案都会让需要实时互动的用户通过核心的语音视频网络，像是BGP之类的优质节点来做传输，也有可能需要做转码、转协议或混流之后，再通过聂荣分发网络去分发。这样一来，在接入核心语音视频网络时就需要有智能的调度策略来完成就近接入了。
2.流畅性
流畅性作为直播过程中容易出现较多技术难点的一个方面，需要注意的也有很多。
（1）可以做动态伸缩的jitterbuffer，在网络状况差或者是网络抖动比较剧烈的情况下，可可以适当增大，从而降低延迟来对应出现的网络抖动情况。
（2）快播和满播技术在网络环境较差时，可以在用户毫无感知的条件下稍微降低播放速度，然后来解决短暂出现的网络抖动所引起的卡顿情况，当网络恢复后，还可以快速追赶回来。需要注意的是，这种方式并不适合所有的应用场景。
（3）码率自适应，也就是说选择合适的码率来做动态传输。为了保证流畅度可以适当调整分辨率和帧率，当然，语音视频引擎会根据当前的网络测速结果和应用需要的码率，动态调整码率、帧率和分辨率，以此达到流畅观看的用户体验。
（4）在推流端做一些分层的编码，这样一来，在拉流端可以动态的根据侦测到的网络带宽情况来拉取不同的数据去做渲染。而分层编码允许拉流端选择不同层次的视频编码数据，网络情况好的时候，就选取较多层次的数据，网络情况差的情况下，就选取基础层次的数据。
（5）在推拉流端监测当前推拉流质量比较差时，即使通过降低码率、分辨率和帧率等策也无法保证质量时，可以选择放弃此链路。
3.回声消除
先简单介绍一下回声消除的原理，对端发送的信号会先给到回声消除的模块，作为将来消除的参考信号，再将信号给到扬声器播放，播放后由于周围环境反射形成回声，与真实的音频输入一同被麦克风采集，这时采集到的输入信号是带有回声的，回声消除模块会根据前面的参考信号生成滤波抵消掉会回声后再发送出去。至于回声消除的问题，谷歌开源的WebRTC提供了回声消除模块，但它本身设计是为了在PC端实现音视频互动场景，在移动端的适应性较差，尤其是Android端。
4.国内外互通
这一点适用于海外运营的用户，流媒体数据和控制信令就需要做好跨国互通，所以要考虑在全球合理布置一些中继节点。数据路径的选择是需要根据业务决定的，也就是说在物理链路路由之上还需要再有一条业务的路由表，并且根据用户的场景制定，比如用户分布、访问频率或高频段峰值等。可能每次的路由都会不同。
5.海量并发
这是所有的互联网相关产品都会遇到的问题，主要考虑负载均衡，如何平滑扩容，对于无法覆盖的地方要做代理调度，甚至需要考虑容灾、接入层的设计等等，再此就不多做赘述。
由此可见，在开发过程中不仅需要优质的一对一语音直播系统源码作为“辅助”，还需要考虑多方面因素和可能发生的问题，只有这样才能开发出真正优质的直播app。如若不然，将会在直播领域中就此“销声匿迹”。
本文转载自网络，感谢（爱吃五花肉吗）的分享，转载仅为分享干货知识，如有侵权欢迎联系云豹科技进行删除处理
