webrtc video jitter详解（一）

webrtc jitter中缓存最近一段时间内的视频数据包，供解码线程取出解码显示。
本文以h264视频为例讲解缓存机制。webrtc先将接收到的rtp包组装成帧数据（vcmframe）

1，h264 rtp传输格式

h264在rtp包中的封装格式如下，以下为借用网络图片

上图的左边的打包流程对应的场景是“NALU的长度 <= MTU”，直接将NALU的header拷贝到H264 RTP Payload Header上，将NALU的RBSP拷贝到H264 RTP Payload Content上。
上图右边的打包流程对应的场景是“NALU的长度 > MTU”，要将NALU的RBSP进行分片，以保证打包后的RTP报文长度不大于MTU，H264 RTP Payload Header由FU-identity + FU Header组成；FU-identity字段和NALU header字段的格式一样（如果不一样的话，接收端就搞不清这是一个NALU分片还是一整个NALU了），其最低的5bits表示payload的类型；FU payload就是NALU的RBSP（一部分）；另外，属于同一H264帧的所有RTP头的时间戳都要打成相同的，接收端根据时间戳来判断哪些包是属于同一个H264帧的。

webrtc中在RtpDepacketizerH264::Parse中解析rtp包
将fua格式的第一个包解析成single包组织方式，其他包去掉2byte头
对于single和stap格式，每个rtp包的marker设置为1。 fua格式，一帧最后一个包的marker设置为1，其他为0

if (is_first_packet_in_frame() && markerBit) { //single
    completeNALU = kNaluComplete;
  } else if (is_first_packet_in_frame()) { //fua第一个包
    completeNALU = kNaluStart;
  } else if (markerBit) { //fua最后一个包
    completeNALU = kNaluEnd;
  } else {  //fua中间包
    completeNALU = kNaluIncomplete;

2，jitterbuffer存储格式

webrtc中VideoCodingModuleImpl是jitter总的接口
vcmpacket对应rtp包，vcmframe对应一个完整的帧（fua格式需要将多个rtppacket合并，这通过sessioninfo完成）
VCMSessionInfo 将rtp packet组装成可解码的frame
VCMFrameBuffer 封装VCMSessionInfo方法
VCMDecodingState 记录当前已经解码帧的最后seq和tiemstamp等信息

frame在jitter中的存储分为decodable_frames_、incomplete_frames_、free_frames_。下面为借用网络上图片

详细可参阅文章https://www.jianshu.com/p/bd10d60cebcd
其中decodable_frames_存储可以解码的帧（比如关键帧或者前序完整的P帧）；
incomplete_frames_存储暂时不能解码的帧：（1）本身rtp包不完整的帧（2）依赖的参考帧不完整的帧

为了更便于理解jitter的存储机制，用以下的逻辑存储格式来描述

• 每个方格为一帧数据vcmframe。
• 绿色表示可解码帧（图中1、2），存储在decodable_frames_
• 红渐变色表示rtp包不完整的帧（图中3、4），存储在incomplete_frames_
• 红色表示rtp包完整，但是依赖的参考帧不完整（图中5、6），存储在incomplete_frames_
• 白色表示还未接收到的包（图中7），存储在missing_sequence_numbers_

1. 每个gop都是以关键帧起始，如果关键帧不完整，那整个gop都不可解吗，必然都是存储在incomplete_frames_中
2. 在一个gop中，可解码帧都是以关键帧起始，然后连续存储在一起的。中间只要有间隔的不完整包或者丢失包，后面都是存储在incomplete_frames_中。如图中的5本身rtp包是完整的，但因为依赖参照帧3、4不完整，本身也不能解码，连锁导致6也不能解码。同样图中12由于依赖参考帧未接收到，暂时也不能解码
3. decode_state记录当前解码到哪一帧，如图中已解码到9，那之前未解码的帧（3～7）都丢弃，未接收到的rtp也不再发送nack请求。

从图中可以看出，未接收到包的重要程度是不同的，11的重要程度大于14，11的不完整影响了12和13的解码。因此在网络拥塞时，可以根据未接收到包的重要程度来优先发送nack请求，尽可能使靠近关键帧的包接收完整。必要情况下可以丢弃重要程度低的nack请求。