1 RTP 的协议描述

实时传输协议RTP（Real-time Transport Protocol）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的，后在RFC3550中进行更新。

         RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTSP协议），视频会议和一键通（Push toTalk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在用户数据报协议上的（UDP）。

        RTP广泛应用于流媒体相关的通讯和娱乐，包括电话、视频会议、电视和基于网络的一键通业务（类似对讲机的通话）。

具体见 https://blog.csdn.net/machh/article/details/51868569。这里不详细描述。

2 RTP 传输中要关注的问题

由于RTP基于UDP非可靠信道传输，面临着UDP 丢包，乱序，延时带来的问题：

延时

“延时”指的是每辆车从鸟巢开到东方明珠花的平均时间。显然，车队走高速公路肯定要比走各种小公路快很多，而且从鸟巢出发沿着怎样的路线开上高速公路也有很大影响，万一堵在了三环可就要多花好几个小时了。所以这个值和车队选择的行驶路线有关。互联网传输也是一样的道理，需要传输数据的两点之间经常是有很多可选路径的，而这些路径的延时往往相差很大。

丢包

“丢包”指的是有的车无法在有效时间内无法达到终点，甚至可能永远也到不了终点。有的车可能永远堵在北京的三环上了，有的车可能中途出了车祸。假如我们的一百辆车里有五辆车因为各种原因没能按时到达上海，我们这次车队传输的“丢包率”就是5%。是的，互联网传输也一样，它并不是百分百可靠的，总有数据无法按时传输到目的地。

抖动

“抖动”指的是车子到达的顺序、间隔和出发时的差异。虽然我们的一百辆车在北京是等间隔的一分钟一辆出发的，但是它们到达上海时却并不是按顺序一分钟一辆到达的，甚至可能有晚出发的车比早出发的车先到的情况。互联网传输也一样，如果简单地按照收到的音视频数据顺序直接播放出来，就会出现失真的现象。

3 RTP 累计众多经验总结的策略

为了对抗网络拥塞、网络波动，解决丢包、延时、抖动的问题，前人总结出了如下四大类策略：

（1）重传请求

检查到丢失的数据包，让对方重新传输。用在此处的协议有NACK, RTX, RPSI

NACK: 现聊一下ack： ACK实际上就是到达通知技术。大家都知道TCP是可靠的连接，他之所以可靠，那是因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。

NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。那么问题来了，接受者怎么知道自己未收到消息？

音视频数据包都是按时间顺序发送的，一般都带序号（升序排列的时间戳）。例如发送方按顺序发送了时间戳为60,120,180,240，320共五个包，接收者已经收到了60包，本来预期下一个接收的包的序号应该是序号120的包，但序号是120的包一直没收到，后面的包却收到了。那么接收者就可以判断，120这个包丢了，这时候接收方需要向发送方发出NACK消息（消息中带有丢包的序号，这里是120），让发送方重新发送丢失的包。

实时音视频传输都基于udp，包到达的顺序是不定的，具体是收不到包就马上出发NACK，还是说需要等待一小段时间看没到达的包是否会到达再决定是否发送NACK，这个具体要带webrtc的代码实现。

RTX: webrtc中默认开启rtx用于丢包重传，rtx的介绍可以参考rfc4588，https://tools.ietf.org/html/rfc4588#section-4

rtx使用额外的ssrc传输，ssrc在sdp中会标识出来。

↵a=rtpmap:97rtx/90000↵a=ssrc-group:FID2736695910239189782

类似这样。

一个RTX包，在turnserver中是这样的，原始udp数据->turn/stun协议头->RTP header1 ->RTP header2

在RTP header1中根据payload type进行区别RTP、RTX数据，如果是RTX的话，需要srtp解出后面的数据，再解析。

在客户端中，RTX封包的关键函数是：

https://code.google.com/p/webrtc/source/detail?r=4692Channel::IsPacketRetransmitted

Channel::HandleRtxPacket

rtp_payload_registry_->IsRtx

RTPPayloadRegistry::RestoreOriginalPacket    移除RTX头, 还原原始的RTP

链接是，webrtc加入rtx的issue

（2）拥塞控制

拥塞控制策略主要基于两种方式：基于丢包检测的拥塞控制 和 基于延时检测的拥塞控制。检测完成之后再根据实际情况进行动态的升、降。

1）基于延迟（delay-based）的拥塞控制算法：

由数据的接收方实现，接收方需要记录每个数据包到达的时间和大小，并计算每个数据分组之间（inter-group）的延迟的变化，由此判断当前网络的拥塞情况，并最终输出码率估计值由RTCP feedback（TMMBR或 REMB）反馈给发送方。

2）基于丢包（loss-based）的拥塞控制算法：

则由数据的发送方来实现，发送方通过从接收方周期性发来的RTCP RR（Receiver Report）中获取丢包信息以及计算RTT，并结合TMMBR或REMB中携带的码率信息算得最终的码率值，然后由媒体引擎根据码率来配置编码器，从而实现码率的自适应调整。

rate control:

状态 Increase： 表明当前没有检测到网络拥塞，在此状态下传输速率需要逐步增加；它先是通过乘性增加来调整速率（乘性因子为1.08），当速率接近临界值时再通过加性增加逐步收敛，而这里所谓的临界值是指上一次在状态Decrease时统计的下行码率；

状态 Decrease： 表明当前检测到了网络拥塞，在此状态下传输速率需要逐步下降；在这里，WebRTC所采用的方法是乘性下降，其乘性因子为0.85；

状态 Hold： 表明保持当前的速率不做改变。

速率控制子系统最终会输出一个带宽估计值A_hat，并通过RTCP Feedback（TMMBR/REMB）请求发送方进行速率调整

（3）关键帧请求

FIR PLI/PLS 协议包配合实现关键帧请求：

FIR: RFC 2032 5.2.1. Full intra-frame Request (FIR) .作用是在关键帧丢失无法解码时，请求发送方重新生成并发送一个关键帧。（Intra Frame其实就是指I帧，Inter Frame指P帧或B帧）。FIR更多是在一个中心化的Video Conference中，新的参与者加入，就需要发送一个FIR，其他的参与者给他发送一个关键帧这样才能解码.

PLI:Picture Loss Indication

PLS:Slice Loss Indication

PLI/PLS 发送方接收到接收方反馈的PLI或SLI需要重新让编码器生成关键帧并发送给接收端，PLI和SLI的含义更多是在发生丢包或解码错误时使用。

（4）丢包恢复

主要是通过 FEC协议实现：

冗余编码 / 前向纠错 FEC

改进型的vandermonde矩阵FEC(Forward Error/Erasure Correction）前向纠错技术来进行丢包恢复，由发送方进行FEC编码引入冗余包，接收方进行FEC解码并恢复丢失的数据包。

发送额外的包来辅助恢复丢失包

FEC技术是一种广泛应用于通信系统中的编码技术。以典型的分组码为例，其基本原理是：在发送端，通过将k bit信息作为一个分组进行编码，加入（n-k）bit的冗余校验信息，组成长度为n bit的码字。码字经过信道到达接收端之后，如果错误在可纠范围之内，通过译码即可检查并纠正错误bit，从而抵抗信道带来的干扰，提高通信系统的可靠性。在光通信系统中，通过FEC的处理，可以以很小的冗余开销代价，有效降低系统的误码率，延长传输距离，实现降低系统成本的目的。

编码开销是校验位长度（n-k）与信息位长度k的比值，称为编码开销。开销越大，FEC方案的理论极限性能越高，但增加并不是线性的，开销越大，开销增加带来的性能提高越小。开销的选择，需要根据具体系统设计的需求来确定。

4 相关的基础知识

视频编码  &  IBP 帧

码率 、 帧率 、 分辨率

视频编码

帧内（Intraframe）压缩也称为空间压缩（Spatial compression）。当压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间的冗余信息，这实际上与静态图像压缩类似。帧内一般采用有损压缩算法，由于帧内压缩是编码一个完整的图像，所以可以独立的解码、显示。帧内压缩一般达不到很高的压缩，跟编码jpeg差不多。

帧间（Interframe）压缩的原理是：相邻几帧的数据有很大的相关性，或者说前后两帧信息变化很小的特点。也即连续的视频其相邻帧之间具有冗余信息,根据这一特性，压缩相邻帧之间的冗余量就可以进一步提高压缩量，减小压缩比。帧间压缩也称为时间压缩（Temporal compression），它通过比较时间轴上不同帧之间的数据进行压缩。帧间压缩一般是无损的。帧差值（Frame differencing）算法是一种典型的时间压缩法，它通过比较本帧与相邻帧之间的差异，仅记录本帧与其相邻帧的差值，这样可以大大减少数据

无损压缩也即压缩前和解压缩后的数据完全一致。多数的无损压缩都采用RLE行程编码算法

有损压缩意味着解压缩后的数据与压缩前的数据不一致。在压缩的过程中要丢失一些人眼和人耳所不敏感的图像或音频信息,而且丢失的信息不可恢复。几乎所有高压缩的算法都采用有损压缩,这样才能达到低数据率的目标。

H264 编解码 及IBP

H264 基于运动画面编码 ： 参照一段时间内图像的统计结果表明，在相邻几幅图像画面中，一般有差别的像素只有10%以内的点,亮度差值变化不超过2%，而色度差值的变化只有1%以内。所以对于一段变化不大图像画面，我们可以先编码出一个完整的图像帧A，随后的B帧就不编码全部图像，只写入与A帧的差别，这样B帧的大小就只有完整帧的1/10或更小！B帧之后的C帧如果变化不大，我们可以继续以参考B的方式编码C帧，这样循环下去。这段图像我们称为一个序列（序列就是有相同特点的一段数据），当某个图像与之前的图像变化很大，无法参考前面的帧来生成，那我们就结束上一个序列，开始下一段序列，也就是对这个图像生成一个完整帧A1，随后的图像就参考A1生成，只写入与A1的差别内容。

I 帧

帧内编码帧（intra picture）,I帧通常是每个GOP（MPEG所使用的一种视频压缩技术）的第一帧，经过适度地压缩，作为随机访问的参考点可以当成静态图像。I帧可以看做一个图像经过压缩后觉得产物，I帧压缩可以得6：1的压缩比而不会产生任何可觉察的模糊现象。I帧压缩可去掉视频的空间冗余信息，下面即将介绍P帧和B帧是为了去掉时间冗余信息。

B 帧

双向预测内插编码帧（bi-directionalinterpolated prediction frame）,既考虑源图像序列前面的已编码帧，又估计源图像序列后面的已编码帧之间的时间冗余信息，来压缩传输数据量的编码图像，也成为双向预测帧

P 帧

前向预测编码在帧(predictive-frame),通过将图像序列中前面已编码帧的时间冗余信息去充分去除压缩传输数据量的编码图像，也成为预测帧。