3986.net
小网站 大容量 大智慧
相关标签
当前位置:首页 >> 计算机软件及应用 >>

H.264RTP封包原理


H.264RTP 封包原理
1. 引言 随着信息产业的发展, 人们对信息资源的要求已经逐渐由文字和图片过渡到 音频和视频, 并越来越强调获取资源的实时性和互动性。但人们又面临着另外一 种不可避免的尴尬, 就是在网络上看到生动清晰的媒体演示的同时,不得不为等 待传输文件而花费大量时间。为了解决这个矛盾,一种新的媒体技术应运而生, 这就是流媒体技术。流媒体由于具有启动时延小、节省客户端存储空间等优势, 逐渐成为人们的首选, 流媒体网络应用也在全球范围内得到不断的发展。其中实 时流传输协议 RTP 详细说明了在互联网上传递音频和视频的标准数据包格式, 它与传输控制协议 RTCP 配合使用,成为流媒体技术最普遍采用的协议之一。 H.264/AVC 是 ITU-T 视频编码专家组 (VCEG) 和 ISO/IEC 动态图像专家 组(MPEG )联合组成的联合视频组(JVT)共同努力制订的新一代视频编码标 准, 它最大的优势是具有很高的数据压缩比率, 在同等图像质量的条件下, H.264 的压缩比是 MPEG-2 的 2 倍以上,是 MPEG-4 的 1.5~2 倍。同时,采用视频编 码层(VCL)和网络提取层(NAL )的分层设计,非常适用于流媒体技术进行 实时传输。本文就是基于 RTP 协议,对 H.264 视频进行流式打包传输,实现 了一个基本的流媒体服务器功能,同时利用开源播放器 VLC 作为接收端,构成 一个完整的 H.264 视频传输系统。 2. RTP 协议关键参数的设置 RTP 协议是 IETF 在 1996 年提出的适合实时数据传输的新型协议。 RTP 协议 实际上是由实时传输协议 RTP(Real-time Transport Protocol)和实时传输控制协 议 RTCP(Real-time Transport Control Protocol)两部分组成。RTP 协议基于多播 或单播网络为用户提供连续媒体数据的实时传输服务;RTCP 协议是 RTP 协议 的控制部分,用于实时监控数据传输质量,为系统提供拥塞控制和流控制。RTP 协议在 RFC3550 中有详细介绍。每一个 RTP 数据包都由固定包头(Header ) 和载荷(Payload)两个部分组成,其中包头前 12 个字节的含义是固定的,而载 荷则可以是音频或视频数据。RTP 固定包头的格式如图 1 所示:

其中比较关键的参数设置解释如下: (1) 标示位 (M ) : 1 位, 该标示位的含义一般由具体的媒体应用框架 (profile ) 定义, 目的在于标记处 RTP 流中的重要事件。 (2)载荷类型(PT):7 位,用来指出 RTP 负载的具体格式。在 RFC3551 中,对常用的音视频格式的 RTP 传输载荷类型做了默认的取值规定,例如,类 型 2 表明该 RTP 数据包中承载的是用 ITU G.721 算法编码的语音数据,采用频 率为 8000HZ,并且采用单声道。 (3)序号:16 位,每发送一个 RTP 数据包,序号加 1。接受者可以用它来 检测分组丢失和恢复分组顺序。 (4)时间戳:32 位,时间戳表示了 RTP 数据分组中第一个字节的采样时间, 反映出各 RTP 包相对于时间戳初始值的偏差。对于 RTP 发送端而言,采样时间 必须来源于一个线性单调递增的时钟。 从 RTP 数据包的格式不难看出,它包含了传输媒体的类型、格式、序列号、 时间戳以及是否有附加数据等信息。 这些都为实时的流媒体传输提供了相应的基 础。而传输控制协议 RTCP 为 RTP 传输提供了拥塞控制和流控制,它的具体包 结构和各字段的含义可参考 RFC3550,此处不再赘述。 3. H.264 基本流结构及其传输机制 3.1 H.264 基本流的结构 H.264 的基本流 (elementary stream,ES) 的结构分为两层, 包括视频编码层 (VCL) 和网络适配层(NAL)。视频编码层负责高效的视频内容表示,而网络适配层负 责以网络所要求的恰当的方式对数据进行打包和传送。引入 NAL 并使之与 VCL

分离带来的好处包括两方面:其一、使信号处理和网络传输分离,VCL 和 NAL 可以在不同的处理平台上实现;其二、VCL 和 NAL 分离设计,使得在不同的 网络环境内, 网关不需要因为网络环境不同而对 VCL 比特流进行重构和重编码。 H.264 的基本流由一系列 NALU (Network Abstraction Layer Unit )组成, 不同的 NALU 数据量各不相同。H.264 草案指出[2],当数据流是储存在介质上 时,在每个 NALU 前添加起始码:0x000001,用来指示一个 NALU 的起始和终 止位置。在这样的机制下,解码器在码流中检测起始码,作为一个 NALU 得起 始标识,当检测到下一个起始码时,当前 NALU 结束。每个 NALU 单元由一个 字节的 NALU 头(NALU Header)和若干个字节的载荷数据(RBSP)组成。其 中 NALU 头的格式如图 2 所示:

F:forbidden_zero_bit.1 位,如果有语法冲突,则为 1。当网络识别此单元 存在比特错误时,可将其设为 1,以便接收方丢掉该单元。 NRI:nal_ref_idc.2 位,用来指示该 NALU 的重要性等级。值越大,表示当 前 NALU 越重要。具体大于 0 时取何值,没有具体规定。 Type:5 位,指出 NALU 的类型。具体如表 1 所示:

需要特别指出的是,NRI 值为 7 和 8 的 NALU 分别为序列参数集(sps) 和图像参数集(pps)。参数集是一组很少改变的,为大量 VCL NALU 提供解 码信息的数据。 其中序列参数集作用于一系列连续的编码图像,而图像参数集作 用于编码视频序列中一个或多个独立的图像。 如果解码器没能正确接收到这两个 参数集,那么其他 NALU 也是无法解码的。因此它们一般在发送其它 NALU 之 前发送,并且使用不同的信道或者更加可靠的传输协议(如 TCP)进行传输,也 可以重复传输。

3.2 适用于 H.264 视频的传输机制 前面分别讨论了 RTP 协议及 H.264 基本流的结构,那么如何使用 RTP 协议 来传输 H.264 视频了?一个有效的办法就是从 H.264 视频中剥离出每个 NALU, 在每个 NALU 前添加相应的 RTP 包头,然后将包含 RTP 包头和 NALU 的数据 包发送出去。下面就从 RTP 包头和 NALU 两方面分别阐述。 完整的 RTP 固定包头的格式在前面图 1 中已经指出,根据 RFC3984[3],这

里详细给出各个位的具体设置。 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。 对于每一个 NALU,根据其包含的数据量的不同,其大小也有差异。在 IP 网 络中,当要传输的 IP 报文大小超过最大传输单元 MTU(Maximum Transmission Unit ) 时就会产生 IP 分片情况。 在以太网环境中可传输的最大 IP 报文 (MTU) 的大小为 1500 字节。如果发送的 IP 数据包大于 MTU,数据包就会被拆开来传 送,这样就会产生很多数据包碎片,增加丢包率,降低网络速度。对于视频传输 而言,若 RTP 包大于 MTU 而由底层协议任意拆包,可能会导致接收端播放器 的延时播放甚至无法正常播放。因此对于大于 MTU 的 NALU 单元,必须进行 拆包处理。 RFC3984 给出了 3 中不同的 RTP 打包方案:

(1)Single NALU Packet:在一个 RTP 包中只封装一个 NALU,在本文中对于小 于 1400 字节的 NALU 便采用这种打包方案。 (2) Aggregation Packet:在一个 RTP 包中封装多个 NALU, 对于较小的 NALU 可以采用这种打包方案,从而提高传输效率。 (3)Fragmentation Unit:一个 NALU 封装在多个 RTP 包中,在本文中,对 于大于 1400 字节的 NALU 便采用这种方案进行拆包处理。 4. H.264 流媒体传输系统的实现 一个完整的流媒体传输系统包含服务器端和客户端两个部分[5][6]。 对于服务 器端,其主要任务是读取 H.264 视频,从码流中分离出每个 NALU 单元,分析 NALU 的类型,设置相应的 RTP 包头,封装 RTP 数据包并发送。而对于客户 端来说,其主要任务则是接收 RTP 数据包,从 RTP 包中解析出 NALU 单元, 然后送至解码器进行解码播放。该流媒体传输系统的框架如图 3 所示。


推荐相关:

RTP封包拆包_电力/水利_工程科技_专业资料。RTP封包...(unsigned long H264SSRC, unsigned H264PAYLOADTYPE...RTP协议学习大总结从原理... 21页 1下载券 H264...


RTP_h264解包源码_IT/计算机_专业资料。/// class CH264_RTP_UNPACK class CH264_RTP_UNPACK { #define RTP_VERSION 2 #define BUF_SIZE (1024 * /// ...


H264 视频文件 帧格式 传输封装等 杂碎_IT/计算机_专业资料。H264 视频文件 帧格式 传输封装等 杂碎的介绍 rfc3984 Standards Track [Page 2] RFC 3984 RTP ...


把其他数据封包RTP 包即可 如有一个 H.264 的 NALU 是这样的: [00 00...RTP协议学习大总结从原理... 21页 1下载券 h264RTP负载结构 8页 免费©...


RTSP/RTP 实现 H.264 视频直播 RTSP/RTP 实现 H.264 视频直播 2012 年 06 月 第1页 RTSP/RTP 实现 H.264 视频直播 文档修订控制记录版本 V1.0 日期 ...


h264RTP负载结构_IT/计算机_专业资料。h264RTP负载结构1. RTP 数据包格式 RTP 报文头格式(见 RFC3550 Page12) : 0 1 2 3 4 5 6 7 8 9 0 1 2...


RTP_h264打包源码_IT/计算机_专业资料。class CH264_RTP_PACK { #define RTP_VERSION 2 typedef struct NAL_msg_s { bool eoFrame ; unsigned char class ...


rtp_hdr =(RTP_FIXED_HEADER*)&sendbuf[0]; //设置 RTP HEADER, rtp_hdr->payload = H264; //负载类型号, rtp_hdr->version = 2; //版本号,此版本...


封包模式,多个 nalu 组成一个 RTP 包 分片封包模式,一般 nalu>mtu H264nalu...RTP协议学习大总结从原理... 21页 1下载券 H.264码流结构解析 3页 免费 H...


浅述H.264 视频的 RTP 荷载格式 本文概况 本文讲述了一种有关于互联网社区的 internet 标准跟踪协议,而 这需要进一步进行讨论和建议改善。 请参考最新版本“互联网...

网站首页 | 网站地图
3986 3986.net
文档资料库内容来自网络,如有侵犯请联系客服。zhit325@qq.com