转自https://blog.csdn.net/ucvive/article/details/78220734
音视频SDK开发包涉及的技术要求
音视频软件开发，也叫音视频即时通信开发。随着互联网的发展，每天都有相当多的人在使用各种网络交流工具，如MSN，腾讯QQ，ICQ，新浪微博。
然而目前大部分网络交流工具都还是以文字为主，语音视频功能大部分还是不够成熟，完全通过网络实现语音视频需要考虑到很多方面，如：硬件、软件、技术、网络;等等。因此，即时通讯软件开发诞生了。
简而言之，即时通讯软件开发就是通过开发一套跨平台的即时通讯音视频解决方案，也就是云智真音视频SDK开发包，它是基于先进的H.264视频编码标准、AAC音频编码标准与P2P技术，整合音视频编码、多媒体通讯开发技术而设计的高质量、宽适应性、分布式、模块化的网络音视频互动平台来满足人们的即时通讯需求。跨平台实时云通讯音视频解决方案详解
即时通讯开发涉及到的技术领域十分广泛，主要涉及以下几个领域：
1、网络技术：
即时通讯讲究的是点对点，或者一对多的通讯。因此，P2P(点对点技术)作为一种网络新技术进入即时通讯开发人员的视野。针对可不经过服务器中转的音视频应用，采用了P2P通信技术，该技术的核心在于防火墙的穿越。使用P2P通信技术，可以大大的减轻系统服务器的负荷，并成几何倍数的扩大系统的容量，且并不会因为在线用户数太多而导致服务器的网络阻塞。支持UPNP协议，自动搜索网络中的UPNP设备，主动打开端口映射，提高P2P通信效率。
2、视频技术：
目前最先进的视频技术非H.264莫属，H.264最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。H.264具有许多与旧标准不同的新功能，它们一起实现了编码效率的提高。特别是在帧内预测与编码、帧间预测与编码、可变矢量块大小、四分之一像素运动估计、多参考帧预测、自适应环路去块滤波器、整数变换、量化与变换系数扫描、熵编码、加权预测等实现上都有其独特的考虑。
3、 音频技术：
选择AAC是最好的即时通讯音频编码标准之一。
AAC于1997年形成国际标准ISO 13818-7。先进音频编码AAC开发成功，成为继MPEG-2音频标准(ISO/IEC13818-3)之后的新一代音频压缩标准。
AAC主要可能的应用范围集中在因特网网络传播、数字音频广播，包括卫星直播和数字AM、以及数字电视及影院系统等方面。AAC使用了一种非常灵活的熵编码核心去传输编码频谱数据。具有48 个主要音频通道，16 个低频增强通道，16 个集成数据流, 16 个配音，16 种编排。?
4、API接口技术：
即时通讯开发必须采用动态缓冲技术来适应不同网络环境(局域网、企业专网、互联网、3G网络)，根据不同的网络状态动态调节相关参数，使得即时通讯平台在多种网络环境下均有良好的表现，并特别针对互联网、3G网络等应用场合进行优化，为上层应用提供视频质量的动态调节接口、音频质量的动态调节接口。
5、保密技术：
即时通讯平台比较通用的保密技术有：
a、自定义服务器端口。服务器所使用的TCP、UDP服务端口均可自定义(在服务器的.ini文件中配置)，实现服务的隐藏;
b、加密传输服务器与客户端之间的底层通信协议。
c、服务器设置连接认证密码。
d、服务器内部设置安全检测机制，一旦检测到当前连接的客户端有非法操作嫌疑(如内部通信协议没有按既定的步骤进行)时，主动断开该客户端的连接，并记录该连接的IP地址，在一段时间内不允许重新连接。
---------------------
作者：可爱小布
来源：CSDN
原文：https://blog.csdn.net/ucvive/article/details/78220734
版权声明：本文为博主原创文章，转载请附上博文链接！
对于一个实时互动的音视频系统而言，存在很多技术难点，有几个比较重要的点：
首先是低延迟，如果要满足比较流畅地进行实时互动，那么单向的端到端的迟延大概要在400毫秒以下才能保证流畅沟通;
第二点就是流畅性，你也很难想象在视频过程中频繁卡顿会有良好的互动;
第三点是回声消除，回声的产生是扬声器播放的声音经过环境反射被麦克风重新采集并传输给对方，这样对方就会一直听到自己的回声，整个互动过程会非常难受;
第四点是国内外互通，随着现在国内同质化产品越来越多，国内的竞争也异常激烈，很多厂商纷纷选择出海，这时就需要做好海内外的互通;
第五点是海量并发，当然这不仅仅指实时音视频了，基本对于任何一款互联网产品而言都是必须要考虑的难点。
技术难点解决方案
关于这几个技术难点，在这里跟大家分享一下ZEGO即构科技的解决思路和实践经验。
1、低延迟 
首先，如果实时音视频要保证低延迟，那么前端和后端的整个链条一定要做到极致的，比如前端的一些编码算法、流控，甚至丢帧、追帧策略等等都要做到足够好。另外，不同的业务场景下，编码器的选择也会有所区别，从而会带来不同的编码延迟，因此不同的业务场景能达到的延迟程度也是不一样的。
其次，就是对推拉流网络的选择，通常的方案是让需要实时互动的用户通过核心语音视频网络——像BGP这样的优质节点来做语音视频传输，而对于一些特定场景来说，比如互动游戏会直播给一些围观用户看，那么这里就需要做转码、转协议、甚至混流，再通过内容分发网络去分发。像 内容分发网络本身天然就有做就近接入，但对于接入核心语音视频网络就需要有智能的调度策略来完成就近接入，以及跨运营商、跨区域的接入，比如可以采用上次登录IP、常用IP和区域调度，甚至可以测速再去连接，当然网络调度的策略也需要根据业务群的分布仔细规划，甚至采用多个策略配置权重的方式。
2、流畅性
要实现流畅性也会有很多的技术难点和策略，我主要会介绍其中几种。第一个是可以做动态伸缩的JitterBuffer（Jitterbuffer :抖动缓冲器在voice over IP(VoIP)中，抖动缓冲器是一个共享的数据区域，在这个数据区域中，每隔一段均匀的间隔，语音包会被收集，存储并发到语音处理器。包到达时间的变化，称作抖动，将会由于网络拥塞，定时漂移或路由变更而产生。抖动缓冲器放于语音连接的接收端，它有意地延迟到达的包，如此一来，终端用户就会感受到一个清晰的，没有什么声音失真的连接。抖动缓冲器有两种，静态的和动态的。静态抖动缓冲器是基于硬件的，它是由厂家来配置的。而动态抖动缓冲器是基于软件的，它由网管配置以适应网络延迟的改变。），在网络较差或者网络抖动比较剧烈的情况下，可以适当增大JitterBuffer，从而降低一点点延迟来对抗抖动。
第二个是快播和慢播技术，在网络较差的环境，可以在用户无感知的条件下稍微降低播放速度，来应对短暂网络抖动引起的立即卡顿，当网络恢复可以加快速度追回来，但这种方式并非适合所有场景，比如对于节奏要求非常准确的唱歌场景，当播放速度稍微放慢就可以被感知。
第三个是码率自适应，也就是以比较合适的码率做动态传输，为了保证流畅度甚至可以调整帧率和分辨率。语音视频引擎会根据当前网络测速的结果和应用所期望的码率，动态地调整码率、帧率和分辨率，最终达到流畅观看的用户体验。
第四个是分层编码、传输控制，在推流端做一些分层的编码，这样在拉流端可以动态根据侦测到的网络带宽情况来拉取不同的数据去做渲染。分层编码允许拉流端取选择不同层次的视频编码数据，网络情况好的时候，就拉取较多层次的数据;网络情况差的情况下，就拉取基础层次的数据。
第五个是动态调度，当在推拉流端监测当前推拉流质量比较差，而且即使通过降低码率、帧率和分辨率等策略已经无法保证质量，这时就可以选择放弃这条链路，直接重新做选入、建立连接，当然在这个过程中可能会出现短暂的停顿。
3、回声消除 
首先介绍下回声消除的原理：对端发送的信号会先给到回声消除的模块，作为将来消除的参考信号，再把信号给到扬声器播放，扬声器播放后由于周围环境反射形成回声，与真实的音频输入一同被麦克风采集，这时采集到的输入信号是带有回声的，回声消除模块会根据前面的参考信号生成滤波抵消掉回声消后再发送出去。
原理听起来会比较简单，但在实际过程中却蕴藏着很多的难点，比如回声消除模块接收的参考信号与最终被环境反射后的回声本身就是存在差异的，此外设备也会极大的影响回声消除，尤其是国内的安卓机型特别多，比如国内某手机厂商，从麦克风采集音频数据到提交中间有将近一百毫秒的延迟，这时回声消除算法如何适应这么长回声延迟的手机就很关键;再比如很多用户在直播中都会用外置声卡，甚至是模拟器，这无形中也会带来回声的延迟。除了设备，场地同样存在很大的相关性，对于普通会议室，设置 40米的回声延迟可能已经足够了，但一些大会场这种回声延迟能达到将近上百米，这也是一种挑战。
关于回声消除，其实谷歌开源的WebRTC提供了回声消除模块，但WebRTC的设计本身是为了在PC端实时音视频互动的场景，在移动端的适应性上就会差一些，尤其体现在安卓的一些低端机上。而相对来说，苹果因为整体硬件、软件全是自己实现的，麦克风、扬声器也都有声学模型设计，因此回声消除的效果会比安卓好很多。即构科技的音视频引擎都是采用自研，在真机和模拟器等1000多的机型上测试过，都可以做到很好的回声消除。
4、 国内外互通 
前面提到很多产品都会选择出海，包括主打国内市场的产品也会有一些海外用户，因此流媒体数据和控制信令就要做好跨国的互通，这就需要考虑在全球合理布置一些中继节点。
这张图就是一个典型的中继续传，北京用户和迪拜用户之间要做视频沟通，根据就近接入原则他们会分别连接当地的节点，而这两个节点间如果互拉，效果会非常差，这时就需要布置适合的中继节点，比如香港、新加坡、日本等等，数据路径的选择是需要根据业务侧决定的，也就是说在物理链路路由之上还要再有一条业务的路由表，需要根据用户场景制定，包括用户分布、用户访问频率、高频段峰值等等，可能每次的路由都会有所不同。
5、海量并发
海量并发是所有互联网产品都会遇到的问题，这里就不再展开，主要要考虑负载均衡，如何平滑扩容，对于无法覆盖的地方要做代理调度，甚至需要考虑容灾、接入层的设计等等。
实时语音视频的技术门槛相对比较高，如果依靠自己研发，可能即使会投入很多开发成本也无法与匹配市场快速发展的节奏。现在实时音视频云服务已经十分成熟，其实不妨“让专业的人去做专业的事”。
原文地址：https://www.cnblogs.com/witRY/p/10758184.html