/**
* @author wangdaopo
* @email 3168270295@qq.com
*/
语音视频SDK的选型标准
一套实时的传输机制
sip是通讯协议， sip只是信令，就是指挥的意思通过它就能指挥谁和谁通话。
常用的音视频流传输的媒体协议： rtp/rtcp/rtsp/rtmp/mms/hls
实时传输协议RTP与RTCP： RTP协议 通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。 传送具有实时属性的数据； RTP控制协议（RTCP）----监控服务质量并传送正在进行的会话参与者的相关信息。 视频会议和视频电话系统（配合H.263或SIP）。
实时流协议RTSP定义了 一对多应用程序如何有效通过IP网络 传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上。 基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。
实时消息传输协议RTMP 工作在TCP之上的明文协议，
HTTP Live Streaming(HLS)是基于HTTP的流媒体传输协议，可实现流媒体的直播和点播。 由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。
MMS（Microsoft Media Server Protocol）是用来访问并流式接收Window Media服务器中.asf文件的一种协议。
RSVP即资源预订协议，使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS。 RSVP在网络层、RTSP在应用层与RTP协议在传输层。
HLS全称为HTTP Live Streaming,是苹果公司提出的基于HTTP的流媒体网络传输协议。
多码率的适配，根据网络带宽，客户端会选择一个适合自己码率的文件进行播放，保证视频流的流畅 .docx
没有一套实时的传输机制，再怎么在各个环节“优化”，也无法获得真正超低的延迟。
要实现超低延迟，信道QoS十分关键。首先要选择合适的网络传输协议， 然后根据网络环境采用合适的QoS技术. 没有任何一种QoS技术能解决所有问题，实时语音视频传输机制必须是多种QoS技术的有机结合。
信道 QoS 的三大措施
如果要选择第三方的语音视频SDK,下述的技术要求也可以成为语音视频SDK的选型标准。
实时语音视频通话要获得超低延迟，不能仅仅依靠在各个环节不断地优化，而是要通过 FEC、ARQ和码率自适应构建实时通讯机制。在这个基础上，还要充分考虑网络情况、实时要求和成本因素，以及需要大量经验数据的支撑（比如说，PLR和RTT的关键阈值等）。
根据丢包率（ PLR, Packet Lost Rate ）来设置冗余度
PLC 全称 Packet Lost Concealment, 意译为错误隐藏，应用于实时语音通话的场景。 错误隐藏 PLC 算法通过前一个语音数据包和后一个语音数据包的相关性来“推测出”当前丢失的语音数据包，从而“隐藏”了信道传输所造成的错误。错误隐藏 PLC 算法在接收端进行，不需要发送端参与。
前向纠错 FEC的校验
丢包重传 ARQ的重传
智能 QoS
需要一套智能的 QoS 策略，既要能对抗网络损伤，又要能保持媒体数据传输的实时性。
上图中有三块区域，代表两个极端情形和一个中间情形：
1） 较弱网络的极端情形：在 RTT>250ms 或者 PLR>10% ， 网络延迟特别大或者丢包率特别高的情况下（蓝白色区域），不使用 ARQ 而使用 FEC ，因为在延迟大或者丢包多的弱网情况下， ARQ 可能会进一步加大延迟。
2） 较好网络的极端情形：在 RTT<70ms 或者 PLR<3% ，网络延迟很小并且丢包率比较低的情况下（深蓝色区域），适合使用 ARQ ，如果对成本不敏感，可以适当使用 FEC 。
3） 中间的情形：在 (RTT<=250ms 而且 PLR<=10%) 的前提下， RTT>=70ms 或者 PLR>=3% 的情况，可以根据成本和体验的考虑，智能地选择使用 FEC 和 ARQ 的权重。
语音数据可以适当地通过 PLC 来恢复，可以减低延迟时间和带宽成本。另外，由于语音数据比起视频数据小好多，与其通过 FEC 和 ARQ 复杂的算法处理，还不如在适当的网络情况下，在一定的时间间隔内发送两次同样的语音数据包，从而达到用冗余数据纠错的效果。
带宽估算
无论是码率自适应、 FEC 还是 ARQ ，都要依赖带宽估算算法来工作。码率自适应根据带宽估算的结果来自动调节码率； FEC 和 ARQ 根据带宽估算的结果来分配冗余数据所占的带宽。
除了带宽估算以外，网络拥塞探测对码率自适应也十分关键。
带宽分配
带宽分配策略是根据网络情况，包括RTT和PLR等因素，来给原始数据包和冗余数据包分配带宽。
智能的带宽分配策略是要在语音视频的质量和QoS信道保护算法的纠错能力之间寻找平衡点。
一般来说 ，带宽分配的策略可以按照下面的方法进行：
1） 总共的带宽由码率自适应 ABC模块估算得出；
2） 丢包重传 ARQ的重传数据包所占带宽根据RTT和PLR估算得出；
3） 前向纠错 FEC的校验数据包所占带宽根据RTT，ARQ恢复后的PLR，和总共的带宽估算得出；
4） 原始数据包所占的带宽根据 ARQ、FEC和总共的带宽计算得出。
上图中左边的坐标系中，纵坐标是带宽，横坐标是 RTT。在RTT比较小的网络情况下，ARQ分配的带宽比较多，不采用FEC；在RTT比较大的情况下，FEC分配的带宽比较多，不采用ARQ。不管使用ARQ还是FEC冗余数据包进行信道保护，原始语音视频数据所占的带宽都要适当牺牲。
上图中右边的坐标系中，纵坐标是带宽，横坐标是 PLR。在PLR比较小的网络情况下，ARQ和FEC冗余包分配的带宽都比较小，甚至没有；在PLR比较大的网络情况下，逐渐给ARQ和FEC增加带宽来增强数据纠错能力，原始语音视频数据所占的带宽也相应降低。
Google BBR拥塞控制算法原理
不像CUBIC这种基于丢包做拥塞控制，常导致瓶颈路由器大量报文丢失，所以重新缓存的平均间隔时间也有了11%提升：
由于网速有变化且接收主机的处理性能有限，TCP还要决定何时发送这些Segment。TCP滑动窗口解决了Client、Server这两台主机的问题，但没有去管连接中大量路由器、交换机转发IP报文的问题，因此当瓶颈路由器的输入流大于其输出流时，便会发生拥塞：
在Linux4.19内核中已经将拥塞控制算法从CUBIC（该算法从2.6.19内核就引入Linux了）改为BBR，而即将面世的基于UDP的HTTP3也使用此算法。
TCP的拥塞控制便用于解决这个问题。在BBR出现前，拥塞控制分为四个部分：慢启动、拥塞避免、快速重传、快速恢复：
BBR通过检测RTprop和BtlBw来实现拥塞控制。什么是RTprop呢？这是链路的物理时延，因为RTT里含有报文在路由器队列里的排队时间、ACK的延迟确认时间等。什么叫延迟确认呢？TCP每个报文必须被确认，确认动作是通过接收端发送ACK报文实现的，但由于TCP和IP头部有40个字节，如果不携带数据只为发送ACK网络效率过低，所以会让独立的ACK报文等一等，看看有没有数据发的时候顺便带给对方，或者等等看多个ACK一起发。
而BtlBw全称是bottleneck bandwith，即瓶颈带宽，我们可以通过测量已发送但未ACK确认的飞行中字节除以飞行时间deliveryRate来测量：
当繁忙的网络出现大幅丢包时，BBR的表现也远好于CUBIC算法。下图中，丢包率从0.001%到50%时，可以看到绿色的BBR远好于红色的CUBIC。大约当丢包率到0.1%时，CUBIC由于不停的触发拥塞算法，所以吞吐量极速降到10Mbps只有原先的1/10，而BBR直到5%丢包率才出现明显的吞吐量下降。
H264 SPS PPS
SPS即Sequence Paramater Set，又称作序列参数集。SPS中保存了一组编码视频序列(Coded video sequence)的全局参数。
所谓的编码视频序列即原始视频的一帧一帧的像素数据经过编码之后的结构组成的序列。
而每一帧的编码后数据所依赖的参数保存于图像参数集中。
一般情况SPS和PPS的NAL Unit通常位于整个码流的起始位置。但在某些特殊情况下，在码流中间也可能出现这两种结构，主要原因可能为：
解码器需要在码流中间开始解码；
编码器在编码的过程中改变了码流的参数（如图像分辨率等）；
从H264码流中获取.在H264码流中,都是以"0x00 0x00 0x01"或者"0x00 0x00 0x00 0x01"为开始码的,找到开始码之后,使用开始码之后的第一个字节的低5位判断是否为7(sps)或者8(pps), 及data[4] & 0x1f == 7 || data[4] & 0x1f == 8.然后对获取的nal去掉开始码之后进行base64编码,得到的信息就可以用于sdp.sps和pps需要用逗号分隔开来.
SDP中的H.264的SPS和PPS串，包含了初始化H.264解码器所需要的信息参数，包括编码所用的profile，level，图像的宽和高，deblock滤波器等。
改善网络状况的建议。
（1）智能流技术 hls
（2）分流（splitting）技术
（3）缓存（caching）技术
（4）内容分发网络（CDN）技术
CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器， 通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有 内容存储和分发技术。 负载均衡系统是整个 CDN 的核心。 负载均衡的准确性和效率直接决定了整个 CDN 的效率和性能。
CDN 网络中包含的功能实体包括 内容缓存设备（一个教室一台云主机）、内容交换机（一栋教学楼）、内容路由器 （一个学校校区） 、 CDN 内容管理系统（ 市教育局，站点 ） 等组成。
