使用RTP传输H.264格式视频

最新推荐文章于 2024-08-20 09:49:02 发布

leif_123

最新推荐文章于 2024-08-20 09:49:02 发布

阅读量6.2k

点赞数 4

分类专栏： Android知识点文章标签： h.264 rtp 视频编码

本文链接：https://blog.csdn.net/leif_/article/details/53324999

版权

Android知识点专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一、H.264码流

H.264功能分为两层：视屏编码层（VCL）和网络提取层（NAL）

VCL：被压缩编码的视频数据序列

NAL：VCL需要封装到NAL单元中进行传输存储

NAL单元分析

Nal头	RBSP	Nal头	RBSP

几个概念：

SODB：数据比特串–>最原始的编码数据
RBSP：原始字节序列载荷–>在SODB后面添加结尾比特（一比特1和若干比特0）字节对齐
EBSP：扩展字节序列载荷–>在RBSP基础上加入仿校验字节（0x03）

原因：在NALU加到Annexb上时，需要在NALU之前添加开始码。如果该NALU对于的slice为一帧的开始则用4位字节0x00000001表示，否则用3位字节0x000001。为了确保NALU主体中不包括与开始码相冲突，在编码时没遇到连续两字节的0就添加一个字节的0x03。解码时在去掉该字节脱壳。

一个NAL单元由：1字节的HAL头即3个定长的字段、1个字节数不定的编码段组成

NAL头：（5bit）NALU类型、（2bit）重要性指示、（1bit）禁止位

NALU类型：1～12由H.264使用，24～31由H.264以外的应用使用。

重要性指示：标志该NAL单元用于重建时的重要性，值越大，越重要。

禁止位：网络发现NAL单元有比特错误时可设置该比特为1，以便接收方丢掉该单元

NAL类型介绍：

（1）参数集：以往视频编解码标准中GOB\GOP\图像等头信息是至关重要的，包含这些信息的包的丢失常导致与这些信息相关的图像不能解码。为此H.264将这些很少变化并且对大量VCL NALU起作用的信息放在参数集中传送。参数集分为两种，即序列参数集和图像参数集。为适应多种网络环境，参数集可以带内传送，也可以采用带外方式传送。

SPS ：序列的参数集(SPS)：包括了一个图像序列的所有信息
PPS ：图像的参数集(PPS)：包括了一个图像所有片的信息。

二、RTP/RTCP协议

RTP 协议是在 1996 年提出的适合实时数据传输的新型协议。

RTP 协议实际上是由实时传输协议RTP（Real-time Transport Protocol）和实时传输控制协议RTCP（Real-time Transport Control Protocol）两部分组成。RTP 协议基于多播或单播网络为用户提供连续媒体数据的实时传输服务；RTCP 协议是 RTP 协议的控制部分，用于实时监控数据传输质量，为系统提供拥塞控制和流控制。

RTP包头格式

一个 RTP 数据包都由固定包头（Header ）和载荷（Payload）两个部分组成，其中包头前12个字节的含义是固定的，而载荷则可以是音频或视频数据。

其中比较关键的参数设置解释如下：

标示位（M ）：1 位，该标示位的含义一般由具体的媒体应用框架（profile ）定义，目的在于标记处RTP 流中的重要事件。
载荷类型（PT）：7 位，用来指出RTP负载的具体格式。在RFC3551中，对常用的音视频格式的RTP 传输载荷类型做了默认的取值规定，例如，类型2 表明该RTP数据包中承载的是用ITU G.721 算法编码的语音数据，采用频率为 8000HZ，并且采用单声道。
序号:16 位，每发送一个 RTP 数据包，序号加 1。接受者可以用它来检测分组丢失和恢复分组顺序。
时间戳：32 位，时间戳表示了 RTP 数据分组中第一个字节的采样时间，反映出各RTP 包相对于时间戳初始值的偏差。对于RTP 发送端而言，采样时间必须来源于一个线性单调递增的时钟。

三、使用RTP传输H.264

使用RTP协议来传输H.264视频一个有效的办法就是从H.264视频中剥离出每个NALU，在每个NALU前添加相应的RTP包头，然后将包含RTP 包头和NALU 的数据包发送出去。

对RTP包头的设置

RTP包头的格式如上图，如下介绍详细设置：

V：版本号，2 位。根据RFC3984，目前使用的RTP 版本号应设为0x10。
P：填充位，1 位。当前不使用特殊的加密算法，因此该位设为 0。
X：扩展位，1 位。当前固定头后面不跟随头扩展，因此该位也为 0。
CC：CSRC 计数，4 位。表示跟在 RTP 固定包头后面CSRC 的数目，没有用到混合器，该位也设为 0x0。
M：标示位，1 位。如果当前 NALU为一个接入单元最后的那个NALU，那么将M位置 1；或者当前RTP 数据包为一个NALU 的最后的那个分片时（NALU 的分片在后面讲述），M位置 1。其余情况下M 位保持为 0。
PT：载荷类型，7 位。对于H.264 视频格式，当前并没有规定一个默认的PT 值。因此选用大于 95 的值可以。此处设为0x60（十进制96）。
SQ：序号，16 位。序号的起始值为随机值，此处设为 0，每发送一个RTP 数据包，序号值加 1。
TS：时间戳，32 位。同序号一样，时间戳的起始值也为随机值，此处设为0。根据RFC3984，与时间戳相应的时钟频率必须为90000HZ。
SSRC：同步源标示，32 位。SSRC应该被随机生成，以使在同一个RTP会话期中没有任何两个同步源具有相同的SSRC 识别符。此处仅有一个同步源，因此将其设为0x12345678。

RTP分包

对于每一个NALU，根据其包含的数据量的不同，其大小也有差异。在IP网络中，当要传输的IP 报文大小超过最大传输单元MTU（Maximum Transmission Unit ）时就会产生IP分片情况。在以太网环境中可传输的最大 IP 报文（MTU）的大小为 1500 字节。如果发送的IP数据包大于MTU，数据包就会被拆开来传送，这样就会产生很多数据包碎片，增加丢包率，降低网络速度。对于视频传输而言，若RTP 包大于MTU 而由底层协议任意拆包，可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU 的NALU 单元，必须进行拆包处理。

RFC3984 给出了3 中不同的RTP 打包方案：

Single NALU Packet:在一个RTP 包中只封装一个NALU，在本文中对于小于 1400字节的NALU 便采用这种打包方案。
Aggregation Packet:在一个RTP 包中封装多个NALU，对于较小的NALU 可以采用这种打包方案，从而提高传输效率。
Fragmentation Unit:一个NALU 封装在多个RTP包中，在本文中，对于大于1400字节的NALU 便采用这种方案进行拆包处理。

四、H.264传输系统实现

一个完整的流媒体传输系统包含服务器端和客户端两个部分。

H.264服务端客户端传设计

对于服务器端，其主要任务是读取H.264 视频，从码流中分离出每个NALU 单元，分析NALU 的类型，设置相应的 RTP 包头，封装 RTP 数据包并发送。而对于客户端来说，其主要任务则是接收 RTP数据包，从RTP 包中解析出NALU 单元，然后送至客户端进行解码播放。该流媒体传输系统的框架如图3 所示：

服务端处理流程如下图4：

H.264解码过程

如下图解码流程图：

NAL 单元解码的流程为:首先从 NAL 单元中提取出 RBSP 语法结构,然后按照如图 4 所示的流程处理 RBSP 语法结构。输入的是 NAL 单元,输出结果是经过解码的当前图像的样值点。

NAL 单元中分别包含了序列参数集和图像参数集。图像参数集和序列参数集在其他 NAL 单元传输过程中作为参考使用,在这些数据 NAL 单元的片头中,通过语法元素 pic_parameter_set_id 设置它们所使用的图像参数集编号;而相应的每个图像参数集中,通过语法元素 seq_paramter_set_id 设置他们使用的序列参数集编号。

参考连接：

http://blog.csdn.net/china_video_expert/article/details/7211302

http://blog.chinaunix.net/uid-23883288-id-3034586.html

http://blog.csdn.net/yu_yuan_1314/article/details/8984179