音视频Qos方案

丢包重传:      当接收方发生丢包，如果丢包的时刻 T1 + rtt_var< 接收方当前的时刻 T2，就认为是丢包了，这个时候就会把所有满足这个条件丢失的报文 ID 构建一个NACK反馈给发送方，发送方收到这个反馈根据 ID 到重发窗口缓冲区中查找对应的报文重发即可。服务器端直到缓冲区里的包都未丢包时，才写入文件，APP端同理。该方法的缺点是增大了端到端的延迟，尤其在丢包大量发生时更为明显(嵌入式端影响不大)。前向纠错FEC ，该方法的优点是视频无延迟，但发送冗余包占用了额外的带宽资源。更为可行的方案是是混合NACK／FEC模式。(服务器端、嵌入式端、APP端)

 

乱序:             可以根据RTP包的序列号来排序, 创建一个接收缓存，先排序，后写入文件。(服务器端、APP端)

 

同步:             根据声音流和图像流的相对时间（即RTP包的时间戳），以及它们的绝对时间（即对应的RTCP包中的RTCP），可以实现声音和图像的同步。(APP端)

 

码率控制:      Google Congestion Control，简称GCC。GCC算法是一种混合了基于丢包和基于时延的方法，原理如下：a、发送端根据丢包调整目标带宽，具体来说：低丢包率（小于2%）时增加目标码率，高丢包率（大于10%）时减小目标码率，丢包率介于二者之间时目标码率保持不变； b、接收端根据时延估计最大带宽，由三个模块组成：排队时延估计、链路过载检测和最大带宽估计模块，三个模块间的关系为：当排队时延小于阈值（根据网络状态自适应调整）时，链路检测结果为underuse；当排队时延大于阈值时，链路检测结果为overuse；介于二者之间时，链路检测结果为normal；最大带宽估计模块的实现是一个表示当前链路状态（Increase、Hold、Decrease）的有限状态机，初始状态为Hold，根据链路检测结果进行状态迁移，并根据迁移后的链路状态和当前接收码率估计最大带宽remb。

APP端通过RTCP REMB反馈到发送端，发送端最终的目标码率应不超过remb值。服务器端通过以下方法降低码率：1、降低发送速度  2、有选择的丢弃数据包，例如P帧(服务器端、APP端)

 

秒开画面：    服务器每次以最快的速度一次性发送10秒的内容，APP先将10秒的内容(10*20/s = 200帧)缓存下来，边缓存边播放，当播放到还剩2秒的时候再向服务器发送请求(RTSP PLAY)，服务器继续发送下一个10秒的内容。(服务器端、APP端)