WebRTC的视频和传统的视频会议类似，采用了RTP的封装方案，本文主要描述的是H.264视频裸码流如何封装成网络传输的RTP的数据包
一般的H.264视频帧的构成如下图所示：
每个视频帧可以由一个或者多个切片（slice）组合而成。其中每个slice都是基于宏块的的组合。每个slice在编码之后被打包进入一个NAL单元。在拿到视频编码后的裸码流之后，WebRTC选择了使用RFC3984的non-Interleaved封装方案。
一. 为什么采用RFC3984 的non-Interleaved方案？
1.关于UDP的传输：
WebRTC为了视频实时通话的低延迟，选择了UDP作为数据的网络传输默认的协议。UDP的传输会收到MTU的限制，一般低于1500个字节。
2.RTP的封装：
H.264视频RTP传输方案是Single NAL Unit的方式进行的，这种方式进行UDP传输的时候限制了每个NAL Unit的大小，而每个NAL Unit又是基于slice进行封装的，进一步限制了slice的划分.也就是说在Single NAL Unit的封装方案下，要求每帧视频编码图像需要切分成多个slice进行编码，码率和分辨率越高，划分的slice会越多。
3.多slice方案和单slice方案：
多个slice优势是可以分片独立编码，但是视频质量弱与单slice的方案，目前大部分应用多采用的都是slice的编码的方案。
基于上面遇到的问题，在RF3984中提供了解决方案。
二. 基于RFC3984打包方案
Single NAL Unit是什么：
这个是RTP最基本的Single NAL打包方案，其中:
F: forbidden_zero_bit， 占1位，在 H.264 规范中规定了这一位必须为 0
NRI: nal_ref_idc， 占2位，取值从0到3，指示这个 NALU 的重要性，取值越大约重要。
Type：nalu是指包含在 NAL 单元中的 RBSP 数据结构的类型，其中0未指，1-19在264协议中有定义，20-23为264协议指定的保留位。24-29在RFC3984中进行了指定。其中STAP-A为24，FU-A为28。可以参见下面两个图：
Type后面的数据为RBSP的数据，需要注意的是编码器的每个slice或者，每帧头一般会有0x0001或者0x001作为起始头，在RTP封装中需要去掉。此外在H.264裸码流数据后面可能还会带有padding的数据由RTP头的padding位决定。
STAP-A 是什么？
STAP-A的作用是可以把连个nalu单元封装在一个RTP包里面进行传输，注意的是-A的格式都是不允许跨帧的，也就是两个nalu单元的时间戳必须是相同的。常见的场景是sps和pps两个小包被合并封装。
见上图，RTP头后面仅跟着STAP-A的头，这个格式F，NRI和Type组合而成，占一个字节，字段定义见前面Single NAL Unit的介绍，这里的Type为24。后面两个字节为第一个nalu单元的长度，后面跟个第一个nalu数据同Single NAL Unit的封装一致，第一个数据结束后，跟着第二个nalu的长度，占2个字节，依次类推。
FU-A是什么？
FU-A的作用是把一个原始的大的nalu切成多个数据包进行传输，主要场景在一个slice比较大的情况。FU-A会比较特殊，有FU-A起始包，FU-A包（如果只切两个包可能没有）和FU-A结束包组成。
3.1 FU indicator
这个头已经很熟悉了，前面出现过多次，对于FU-A，type查前面的表可以知道是对应28.
3.2 FU header
这个头占一个字节，其中
S： 占1位如果是1表示当前这个包是FU-A的起始包
E： 占1位如果是1表示当前这个包是FU-A的结束包
R： 占1位，保留位，为0
Type： 实际包含的nalu的类型，见前面的表格
总结一下：
以上就是出现在sdp协商中的mode 1方式所支持的RFC3984包，这种方式在3984协议叫做叫做non-Interleaved，非交错模式，简单理解就是在一次封装的单元中必须是同一帧的数据。在协议中还支持Interleaved模式,交错模式，这种模式允许不同的帧做打包，考虑到传输的实时性，出现的比较少，需要协商出mode 2的能力，这种情况打包和解包需要支持STAP-B，MTAP16，MTAP24以及FU-B格式，实际应用很少见，有需要可以参考协议文档。
