我们之前所开发的视频播放器和录屏软件都只是处理本地的视频文件，没有涉及到任何网络相关的，然而实际情况中，更多的还是涉及到网络通信的。

现在我们是时候开始整网络相关的了，就先从一个局域网内的屏幕共享软件开始吧。

一个屏幕共享软件大致实现如下功能：

发送端：

    1.采集屏幕

    2.编码成h264

    3.发送这个h264数据

接收端：

    1.接收数据

    2.解码h264

    3.显示

采集、编码、解码以及显示 我们之前的播放器和录屏软件中都有实现了，现在重点讲解网络发送和接收。

先从发送开始：

从前面讲解的H264数据特性中可以知道，我们只需要将一个个的NALU发送出去就可以了。

熟悉socket编程的都知道，发送一个数据包可以直接用udp或者tcp协议发送，我们要发送的视频数据也不例外。

但我们不能直接发送这个NALU，因为直接发送出去的话，接收端很难解析还原，我们还需要给数据包加个头部信息，这样才能方便接收端解析。

通过百度之后，我们发现了一个更好的协议：RTP协议。

RTP协议也就是在NALU数据加了一个头部信息而已，只不过他已经成了一种标准，因此我们直接用这个协议来实现。

开始写代码之前，我们先来了解下RTP协议：

以下关于RTP协议的解析来自：https://blog.csdn.net/chen495810242/article/details/39207305

1、RTP Header解析

                                                                图1(rtp header格式解析)

1) V：RTP协议的版本号，占2位，当前协议版本号为2

2) P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。

3) X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头

4) CC：CSRC计数器，占4位，指示CSRC 标识符的个数

5) M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。

6) PT: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。

7) 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。

8) 时戳(Timestamp)：占32位，必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

9) 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

10) 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理

2、RTP荷载H264码流

                                                                                图2

荷载格式定义三个不同的基本荷载结构，接收者可以通过RTP荷载的第一个字节后5位（如图2）识别荷载结构。

1)   单个NAL单元包：荷载中只包含一个NAL单元。NAL头类型域等于原始 NAL单元类型,即在范围1到23之间

2)   聚合包：本类型用于聚合多个NAL单元到单个RTP荷载中。本包有四种版本,单时间聚合包类型A (STAP-A)，单时间聚合包类型B (STAP-B)，多时间聚合包类型(MTAP)16位位移(MTAP16), 多时间聚合包类型(MTAP)24位位移(MTAP24)。赋予STAP-A, STAP-B, MTAP16, MTAP24的NAL单元类型号分别是 24,25, 26, 27

3)   分片单元：用于分片单个NAL单元到多个RTP包。现存两个版本FU-A，FU-B,用NAL单元类型 28，29标识

常用的打包时的分包规则是：如果小于MTU采用单个NAL单元包，如果大于MTU就采用FUs分片方式。

因为常用的打包方式就是单个NAL包和FU-A方式，所以我们只解析这两种。

2.1、单个NAL单元包

                                                                            图3

    定义在此的NAL单元包必须只包含一个。这意味聚合包和分片单元不可以用在单个NAL 单元包中。并且RTP序号必须符合NAL单元的解码顺序。NAL单元的第一字节和RTP荷载头第一个字节重合。如图3。

    打包H264码流时，只需在帧前面加上12字节的RTP头即可。

2.2、分片单元（FU-A）

                                                                        图4

分片只定义于单个NAL单元不用于任何聚合包。NAL单元的一个分片由整数个连续NAL单元字节组成。每个NAL单元字节必须正好是该NAL单元一个分片的一部分。相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包）。相似，NAL单元必须按照RTP顺序号的顺序装配。

   当一个NAL单元被分片运送在分片单元(FUs)中时，被引用为分片NAL单元。STAPs,MTAPs不可以被分片。 FUs不可以嵌套。 即, 一个FU 不可以包含另一个FU。运送FU的RTP时戳被设置成分片NAL单元的NALU时刻。

   图 4 表示FU-A的RTP荷载格式。FU-A由1字节的分片单元指示（如图5），1字节的分片单元头（如图6），和分片单元荷载组成。

S: 1 bit 当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始，开始位设为0。

E: 1 bit 当设置成1, 结束位指示分片NAL单元的结束，即, 荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的 FU荷载不是分片NAL单元的最后分片,结束位设置为0。

R: 1 bit 保留位必须设置为0，接收者必须忽略该位

打包时，原始的NAL头的前三位为FU indicator的前三位，原始的NAL头的后五位为FU header的后五位。

打包时，FUindicator的F、NRI是NAL Header中的F、NRI，Type是28；FU Header的S、E、R分别按照分片起始位置设置，Type是NAL Header中的Type。

解包时，取FU indicator的前三位和FU Header的后五位，即0110 0101（0x65）为NAL类型。

3、RTP打包AAC数据

AAC封装RTP比较简单

将AAC的ADTS头去掉

12字节RTP头后紧跟着2个字节的AU_HEADER_LENGTH,

然后是2字节的AU_HEADER(2 bytes: 13 bits = length of frame, 3 bits = AU-Index(-delta)))，之后就是AAC payload。

所以要得到AACpayload

payLen= （UINT16）usAuheader >> 3;（这里要注意usAuheader的值，RTP中是网络序的，要转成主机序）

具体见RFC3640。

学习音视频技术欢迎访问 http://blog.yundiantech.com  

音视频技术交流讨论欢迎加 QQ群 121376426