如何实现H.265的RTP的封装及传输

一、RTP协议概述
RTP(Real-time Transport Protocol)实时传输协议,由IETF的多媒体传输工作小组发布的网络传输协议,标准为RFC3550/3551。RTP协议支持TCP和UDP两种传输方式,RTP协议负责对流媒体数据进行封包并实现媒体流的实时传输,但并不能为按顺序传送的数据包提供可靠的传送机制,也不提供流量和拥塞控制,这些是依靠RTCP协议来完成的,两者配合使用。本文主要从数据处理的角度实现对H.265的RTP封装进行详细介绍。

二、RTP协议解析
RTP协议是由RTP Header和RTP Payload两部分组成的,具体如下图所示:在这里插入图片描述
1、RTP Header
在这里插入图片描述
RTP头部前12个字节的含义是固定的,具体的含义如下所示:
V:RTP协议的版本号,占2位,当前协议版本号为2。
P:填充标志,占1位,如果P=1,则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。
X:扩展标志,占1位,如果X=1,则在RTP报头后有一个扩展头。
CC:CSRC计数器,占4位,指示CSRC 标志符的个数。
M: 标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。
PT: 有效荷载类型,占7位,用于说明RTP报文中有效载荷的类型。
sequence number:序列号,占16位,用于表示发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。这个字段当下层的承载协议用UDP的时候,网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序,序列号的初始值是随机的,同时音频包和视频包的sequence是分别计数的。
timestamp:相对时间戳,占32位,反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。
SSRC:同步信源标识符,占32位,用于标志同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。
CSRC:特约信源标志符,每个CSRC标识符占32位,可以有0~15个。每个CSRC表示了包含在该RTP报文有效载荷中的所有特约信源。
2、RTP Payload
(1) 单个NALU包模式
在这里插入图片描述
PayloadHdr:单包模式下其值为H.265的NALU Header。

NAL unit payload data:负载数据。

示例:

[00 00 00 01 40 01 0c 01 ff ff 01 60 70 82…]

以上为一个H.265 NALU单元VPS,按单包封装为RTP格式如下:

[RTP Header] [40 01 0c 01 ff ff 01 60 70 82…]

即NALU单元去掉开始头,直接作为RTP Payload加上RTP Header进行发送即可。

(2)分包模式
在这里插入图片描述
PayloadHdr:与H.265 NALU Header结构一致,只是修改了其中的Type类型,Type=49。

FU header:具体组成如下所示
在这里插入图片描述
S:1bit,值为1表示分包开始,其余情况为0。

E:1bit,值为1表示分包结束,其余情况为0。

FUType:等于H.265 NALU Header中的Type类型。

[00 00 00 01 26 01 af 1d 78 06 90 …]

开始包:

[RTP Header] [62 01 93 …]

中间包:

[RTP Header] [62 01 13 …]

结束包:

[RTP Header] [62 01 53 …]

三、H265封装示例
读取一个H.265文件,封装为RTP协议格式进行传输,具体实现如下所示:
(1)单包模式
在这里插入图片描述
(2)分包模式
开始包:
在这里插入图片描述
中间包:
在这里插入图片描述
结束包
在这里插入图片描述

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值