RTP传输视频数据的两个细节

最近接到一个工做，为视频会议的视频编码增长一种VP8格式。整个流程包括VP8的编码，封包，发送，接收，解包，解码。在学习这一部分的代码时，注意到两个细节：一，对于压缩后大于1000字节的视频数据进行了拆包，既把较大的视频数据封装成多个RTP包进行发送。二，视频数据并非拆包后当即发出，而是进入一个队列，根据必定条件进行等待后再发出。
那么，为何要进行这两个处理呢？

背景

视频数据的特征

观察项目中的音频数据，是并无这两个处理的。那么音频和视频有什么不一样呢？
音频数据是每20ms获得一帧数据，每一帧比较小。以48000K，单声道为例，48000 * 20 / 1000,也就960个采样，每一个采样16位，也就1920字节，通过压缩，确定是小于1000字节的。
而视频数据不一样，视频的数据量远远大于音频(几十甚至上百倍)，特别是关键帧，一帧数据压缩后依然很是大。也就是一瞬间，会产生大量的数据待发。

RTP一般是基于UDP的

另外一方面，RTP（实时传输协议）虽然能够基于不一样的网络，但为了提升实时性，仍是基于UDP为多。咱们项目中，就是基于UDP发送的。UDP是一个无链接，不保障的网络协议。

缘由解析

为何须要拆包

UDP能接受的最大包，大约是64K左右。若是向UDP发送一个大包，会在下层自动拆分红多个包（网络底层对于包大小是有限制的，大约1500字节。）。接收端把全部拆分包都收齐之后，从新组装成UDP大包，交给应用层。然而UDP是不可靠链接，包有可能丢。若是一个大包，须要在底层拆为10个包，那么10个包里的任意一个丢失，UDP包都没法组装，从而致使整个包被丢弃。因此，能够看出，越大的包越容易丢包。而若是在应用层拆为10个包发送，丢了其中一个，不论是重传，仍是经过其余方式恢复，掩盖被丢掉的那一个，都比对整个大包进行处理更容易。

为何须要等待

UDP没有流量控制，应用程序向UDP发起发送，UDP就会马上把数据发出去。然而，若是此时接收端的缓存满了，虽然接收端收到了数据，可是由于没地方放，就会丢掉这个数据，造成丢包。而因为视频一帧，尤为是I帧的数据量很大，若是不进行等待，一股脑全丢给网络，则很容易出现接收端到收到了前几个包，然后几个包怎么也收不到的状况。因此在发送视频数据时，应当有等待机制，发送必定量的包后，稍微等待一下，再接着发剩下的包。

UDP vs TCP

在这里顺便补充一下UDP与TCP的差异

	TCP	UDP
数据	面向流	面向消息
链接	面向链接	无链接
顺序	保序	不保序
到达	保证到达	不保证到达
流量控制	有	无
拥塞控制	有	无
延迟	高	低