h.264收发封包解包

furry55

已于 2024-05-19 10:25:00 修改

阅读量144

点赞数

文章标签：后端

于 2023-09-21 14:53:34 首次发布

本文链接：https://blog.csdn.net/furry55/article/details/133133441

版权

1. V：当前的协议的版本号是2，其中0和1已经在草案规范中被占用，这里基本就是固定值了；

2. P：填充标记，包的末尾包含了一个或者多个填充字节，其中填充字节的第一字节包括了后面填充字节的长度，该长度字段包含自己，主要是为了一些对齐处理；

3. X位，如果为1则说明有扩展头，一般默认为0，很少有场景会用到；

4. CC位：是为了计算后面有多少个CSRC，四位说明则最大支持15个CSRC，一般默认为0。

5. M位：特别对于视频而言就是一帧的结束，视频帧比较大，需要通过多个NALU来传输，当看到M位为1时就认为是这个I帧的结束，由于音频帧比较小，一个RTP包就是一个音频帧，所以该位直接置1。

6. Sequence number序列号：16位，用于标识发送者发送的RTP报文序列号，每发送一个RTP包，则这里就增加1，当达到最大值后，则重新从0开始。刚才说了一般RTP协议是承载协议是UDP，UDP是不可靠传输协议。那我们如何保证接收端收的数据是正确的呢，就是通过这个字段进行重新排序，所以接收端一般收到RTP数据第一件事就是排序。

7. timestamp时间戳：占32位四字节，这个单位要注意是采样率到倒数，不是真实的时间，一般要根据采样率进行换算。这里反应的RTP报文第一个八位组的采样时刻，目的是为了接收端计算延迟、抖动和音视频同步。需要说明的是，一个视频帧的时间戳是相同的，但是一个视频帧数据量很大可能需要多个RTP包传输，这样就存在多个RTP包时间戳相同的情况，音频帧数据小，不存在音频帧跨RTP的情况，所以不存在这个问题。

8. SSR同步信号源：占32位四字节，用于标识同步信号源，这个值只要保证在一路音视频会话里面值不相同即可。该标识符是随机选取的 RFC1889推荐了MD5随机算法。该值的作用就是在会话中标识RTP负载流的身份，给一个唯一标记值。

9. CSRC特约信号源CSRC:同样是32位，四字节。一个RTP头最多可以含有0-15个，如果是1对1的流媒体传输，这个字段就不用处理，直接忽略该字段。但是混流和混音时，则需要把各方的RTP同步信号源列出来，这样接收端就能正确指出交谈双方的身份。

1 h264 码流结构

1.1 h264 原始码流

H.264 原始码流（又称为裸流），是由一个接一个的 NAL 单元组成的（NAL Header 加上 RBSP 组成一个 NAL 单元），结构如下图所示：

1.2 h264 NAL 单元

NAL 单元由 NAL Header 和 RBSP 构成。

NAL Header 的结构如下：

占一个字节，由三部分组成forbidden_bit(1bit)，nal_reference_bit(2bits)（优先级），nal_unit_type(5bits)（类型）

forbidden_zero_bit，第 0 位，表示禁止位，一般为值为 0，值为 1 表示语法错误。
nal_ref_idc，第 1-2 位，表示当前 NAL 的优先级。取值范围为 0-3，值越高，表示当前 NAL 越重要，需要优先受到保护。H.264 规定如果当前 NAL 是属于参考帧的片，或是序列参数集，或是图像参数集这些重要的数据单位时，本句法元素必须大于 0。但在大于 0 时具体该取何值，却没有进一步规定，通信双方可以灵活地制定策略。
nal_unit_type，第 3-7 位，表示当前 NAL 单元的类型。具体类型定义如下表：nal_unit_type=5 时，表示当前 NAL 是 IDR 图像的一个片，在这种情况下，IDR 图像中的每个片的 nal_unit_type 都应该等于 5。注意 IDR 图像不能使用片分区。