GB28181协议实现系列之----IPC音视频PS封装（5）

RTP封装PS

RTP报文头格式（见RFC3550 Page12）：

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 12 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P|X| CC |M| PT | sequence number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| synchronization source (SSRC) identifier |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| contributing source (CSRC) identifiers |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

以上域具体意义如下：
版本(V):2比特此域定义了RTP的版本.此协议定义的版本是2.(值1被RTP草案版本使用,值0用在最初"vat"语音工具使用的协议中.)
填料(P):1比特若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分.填料的最后一个字节包含可以忽略多少个填充比特.填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包.
扩展(X):1比特若设置扩展比特,固定头(仅)后面跟随一个头扩展.
CSRC计数(CC):4比特 CSRC计数包含了跟在固定头后面CSRC识别符的数目.
标志(M):1比特标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围.规定该标志在静音后的第一个语音包时置位.

负载类型(PT):7比特此域定义了负载的格式,由具体应用决定其解释.协议可以规定负载类型码和负载格式之间一个默认的匹配.其他的负载类型码可以通过非RTP方法动态定义.RTP发射机在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流.
序列号（sequence number）:16比特每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难.

时间标志（timestamp）:32比特时间标志反映了RTP数据包中第一个比特的抽样瞬间.抽样瞬间必须由随时间单调和线形增长的时钟得到,以进行同步和抖动计算.时钟的分辨率必须满足要求的同步准确度,足以进行包到达抖动测量.时钟频率与作为负载传输的数据格式独立,在协议中或定义此格式的负载类型说明中静态定义,也可以在通过非RTP方法定义的负载格式中动态说明.若RTP包周期性生成,可以使用由抽样时钟确定的额定抽样瞬间,而不是读系统时钟.例如,对于固定速率语音,时间标志钟可以每个抽样周期加1.若语音设备从输入设备读取覆盖160个抽样周期的数据块,对于每个这样的数据块,时间标志增加160,无论此块被发送还是被静音压缩.
时间标志的起始值是随机的,如同序列号.多个连续的RTP包可能由同样的时间标志,若他们在逻辑上同时产生.如属于同一个图象帧.若数据没有按照抽样的
顺序发送,连续的RTP包可以包含不单调的时间标志,如MPEG交织图象帧.

同步源（SSRC）:32比特 SSRC域用以识别同步源.标识符被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符.尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突.若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源.

有贡献源（CSRC）列表:0到15项,每项32比特 CSRC列表识别在此包中负载的有贡献源.识别符的数目在CC域中给定.若有贡献源多于15个,仅识别15个.CSRC识别符由混合器插入,用有贡献源的SSRC识别符.例如语音包,混合产生新包的所有源的SSRC标识符都被陈列,以期在接收机处正确指示交谈者.

注意：前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表.

RTP报文扩展头格式（见RFC3550 Page18）：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 12 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| defined by profile | length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| header extension |

| .... |

若RTP头中的扩展比特位X置1,则一个长度可变的头扩展部分被加到RTP固定头之后,.头扩展包含16比特的长度域,指示扩展项中32比特字的个数,不包括4个字节扩展头(因此零是有效值).RTP固定头之后只允许有一个头扩展.为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展,扩展项的前16比特用以识别标识符或参数.这16比特的格式由具体实现的上层协议定义.基本的RTP说明并不定义任何头扩展本身。

我们采用的是标准RTP头格式，有12bytes的头数据，如上面所描述。

需要注意的是：在封装PS的RTP流时根据28181的标准书上说描述的规范，整个RTP头可以如下进行编码：

其中需要变化是:

sequence number，这个数值是单调递增的，定义的时候为符号整形。每进行一次RTP打包都要进行一次加1操作。

Timestamp，这个时间戳可以自己定义从0开始，按当前帧率去计算时间戳的递增值，值的计算为90000/帧率，如25帧，递增的值就为3600，同一帧的时间戳是不变的。也可以直接从h264的码流中读取当前时间戳无需从0开始，同一帧的时间戳是不变的。

SSRC：按照标准，是向接收者提供声明用的，此值设为0x0即可。

视频从IPC获取到H264数据后必须经过PS封装，PS的封装时根据MPEG-2 Program Stream进行数据封装的，具体可以参考PS封装的相关文档，对于H.264的封装成PS流必须注意一下几点：

1. 必须根据标准书P60,C.1描述进行，H.264在PS的system pack中的stream_type为0x1b。

2. 对于ES流的H.264裸数据首先进行PS封装后再经过RTP封装发送至SIP服务器，sip服务器解码播放，在I帧和P帧的的封装如下：

● I帧

I帧封装顺序

因为RTP的MTU有限制，而对于一帧数据PS分包的情况下，同样可以进行分片处理，而我们获取的是视频数据的实时流，综合分析可以知道，我们应该采用的封装方式是在RTP的MTU的后面跟的PES包长度加上MTU减去的PES包长度的h264数据即为MTU的总长度。

例如：

MTU = 1192+12+19

其中，1192为h264分片数据，12为RTP的固定头长，19

PES包的固定头长。

对于分片最后的那包小于1192长度的数据，会以实际长度进行封包，PES里面填写实际包长数据。

RTP包12字节内容将根据RFC2250标准执行，具体数据情况通过对我抓取的视频包就可以知道RTP12字节头结构，需要注意的是一帧数据的时间戳是相同的，包序列是单调递增的，Mark位都是0。SSRC一直都为0x00。

音频

音频数据也是实时流，根据标准书描述，我们从IPC那里获取的是G711数据，必须在PS包的system的stream_type声明音频为0x90。

对于音频的封包情况只需要在视频的后面增加相关的音频数据即可，如果有音频数据了就进行如下封装

音频数据封装

。

GB28181协议实现系列之----IPC音视频PS封装（5）相关推荐

GB28181协议实现系列之----IPC实时视频点播（4）
实时视频点播是IPC设备接入平台的最主要的功能,平台向设备获取流媒体的过程就是这个过程,设备收到这个点播请求,在交互完成会向平台推送音视频流媒体. 1. 实时点播是由SIP服务器向IPC发 ...
【音视频开发系列】盘点音视频直播RTSP/RTMP推流一定会遇到的各种坑，教你快速解决
聊聊RTSP/RTMP推流那些坑 1.推流架构分析 2.推流缓存队列的设计 3.FFmpeg函数阻塞问题分析 [音视频开发系列]盘点音视频直播一定会遇到的各种坑,教你快速解决更多精彩内容包括:C/C ...
【网络通信 -- 直播】音视频常见封装格式 -- MEPG2 TS
[网络通信 -- 直播]音视频常见封装格式 -- MEPG2 TS [1]相关码流基本概念 ES 流(Elementary Stream)基本码流,直接取自编码器的数据流,可以为音频(AAC 等).视 ...
RTP协议解析及H264/H265 音视频RTP打包分析
一概述实时传输协议(Real-time Transport Protocol或简写RTP)是一个网络传输协议,它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的. RTP协议详 ...
GB28181协议实现系列之----PS流封装（6）
前面的文章收到了不少同仁希望我开放源码,由于之前时间太忙了,一直在做另外产品线的架构设计及架构演化,核心模块的编码,关键技术问题解决等工作确实有较长的时间未继续写文章了.以至于博客的排名越来越低,从2 ...
【解决方案】物流行业如何通过国标GB28181协议国标平台EasyGBS建立车载视频可视化监控系统？
全国物流行业在中国经济迅速发展的同时获得迅速壮大,每个地区都有着数量庞大的物流运输车辆.随着物流运输车辆数量的增长,逐渐暴露出很多车辆管理上的漏洞,使得物流企业的进一步壮大发展,受到很大限制. 目前, ...
技术系列课｜音视频测试实战——记音视频测试那些事
2020年持续火热的直播带货.在线教学.视频会议产品,让越来越多的人开始钻研并专注在音视频技术领域.音视频质量是如何一步步提升的?QA人员日常是如何做评测的?本次分享中,网易智慧企业部资深音视频测试工 ...
音视频解封装：MP4核心Box详解及H264AAC打包方案
问题背景: 上一篇文章<音视频封装:MP4结构概述和分析工具>让大家看了下MP4的主要结构和推荐了一些分析工具,如果你对MP4没有任何了解,还是先看上文,了解MP4的基本结构,其中还有许 ...
FFmpeg 音视频转封装（MP4与FLV互转，流数据转FLV、MP4）
1.简介音视频文件转封装操作就是把一种格式转换为另外一种格式,例如从 flv 转到 MP4,或者把流地址数据转换为MP4. 本文主要讲解流地址数据转为 flv文件. 2.流程 2.1 在使用FF ...

GB28181协议实现系列之----IPC音视频PS封装（5）

RTP封装PS

音频

GB28181协议实现系列之----IPC音视频PS封装（5）相关推荐

最新文章

热门文章