音视频学习：国标协议-拆解二进制网络包

qq_38998001

已于 2024-04-25 11:49:23 修改

阅读量670

点赞数 6

文章标签：音视频学习网络

于 2024-04-19 10:12:06 首次发布

本文链接：https://blog.csdn.net/qq_38998001/article/details/137950341

版权

这篇文章详细解析了GB28181国标协议在音视频传输中的应用，从IP报文、UDP包头、RTP包头到PS包数据，以及如何通过网络抓包分析码流，包括SIP、SDP、RTP、RTCP等协议的作用。作者还讨论了RTP和PS协议的重要性以及码流分析的常见思路。

摘要由CSDN通过智能技术生成

音视频学习：国标协议-拆解二进制网络包

GB28181从最外层ip协议一路解析到es流

前言

GB28181协议是由公安部牵头实现的安防行业统一的设备接入、流媒体传输的协议。
目前基本所有的安防设备厂家的摄像头、NVR、视频平台都支持GB28181协议，是各家设备统一接入管理最好的标准。
可以理解为GB28181是在国际通用标准的基础之上进行了私有化定制以满足视频监控联网系统互联传输的标准化需求。
国标协议可以完成设备接入，管理，语音对讲，直播，回放等各种功能，同时支持保活机制，安全技术，所以国标协议包含各种国际标准技术：
28181协议规范中涉及到SIP、SDP、RTP、RTCP、RTSP等应用层协议，其中SIP+XML主要用于消息交互，SIP+SDP主要用户视频会话，RTP/RTCP主要用于媒体流传输控制，RTSP主要用户录像回放。
本文主要从数据包角度拆解国标协议传输时的各种协议。

一、GB协议的大致过程

1、设备注册
2、设备保活
3、视频流传输
服务端发送INVITE给ipc，ipc回复200ok和ack消息表示可以发流了。
GB协议和各类国际标准的协议的关系：
在这里插入图片描述

二、拆解ip报文

1.帧信息：从数据包中提取的大致信息，不和二进制文件一一对应
2、Linux cooked capture v1：一种特定于Linux系统的数据包捕获模式。在这种模式下，数据包不包含以太网帧头部
Linux cooked capture v1：表示这是使用Linux cooked模式进行的数据包捕获，即Linux内核直接处理数据包而非交由网络接口设备驱动处理。

Packet type: Sent by us (4)：表示这个数据包是由本机发送的。
Link-layer address type: Ethernet (1)：表示链路层地址类型为以太网地址类型。
Link-layer address length: 6：表示链路层地址长度为6字节。
Source: Xensource 28:7c:d7 (00:16:3e:28:7c:d7)：表示数据包的源MAC地址为00:16:3e:28:7c:d7，Xensource可能是发出该数据包的设备或厂商名称。
Unused: 0000：表示未使用的字段。
Protocol: IPv4 (0x0800)：表示该数据包中的网络层协议为IPv4。
Trailer: f80500003570036608dd213494050000：可能是数据包的尾部信息，包含了各种标识和数据，可能用于检验或传输过程的一些控制信息。
在这里插入图片描述
3、ip协议数据包：

三、解析udp包

udp包头介绍

在这里插入图片描述

UDP报文结构由UDP报头和UDP载荷两部分构成,UDP报头由源端口,目的端口,UDP报文长度和校验和构成,其中每个部分占2个字节,共8个字节.
源端口:表示发送方所绑定的进程
目的端口:接收方所绑定的进程
UDP报文长度:表示UDP报文的长度是2个字节,共64kb
检验和:主要用来校验接收的数据是否是发送方传输的数据
解析：
在这里插入图片描述

四、解析rtp包

rtp包头介绍

在这里插入图片描述

V (Version)：2 bits，RTP协议的版本号。
P (Padding)：1 bit，填充位，指示RTP数据包末尾是否有附加的填充字节。
X (Extension)：1 bit，扩展位，指示RTP头部是否包含扩展字段。
CC (CSRC Count)：4 bits，CSRC计数器，指示CSRC列表中包含的CSRC标识符的数量。
M (Marker)：1 bit，标记位，用于指示帧的重要性或分段的结束。
PT (Payload Type)：7 bits，负载类型，指示RTP负载的类型，例如音频或视频编码类型。
Sequence Number：16 bits，序列号，用于标识RTP数据包的顺序。
Timestamp：32 bits，时间戳，用于表示RTP数据包的时间戳，通常是音频或视频数据的采样时刻。
Sync Source Identifier (SSRC)：32 bits，同步信源标识符，用于标识RTP流的同步源。
Contributing Source (CSRC)：32 bits，贡献源标识符，可选字段，用于标识贡献到此RTP数据包的源。
Payload Data：RTP负载数据，根据负载类型不同而变化，可以是音频、视频或其他类型的数据。

解析rtp包

rtp包头示例：80 08 00 05 8f 21 4e c8 a9 68 d2 ad
具体含义如下：

80：版本号(2 bits) + 填充位(1 bit) + 扩展位(1 bit) + CC计数器(4 bits)；这里版本号为2，填充位和扩展位都为0，CC计数器为0。
08：标记位(1 bit) + 负载类型(7 bits)；这里标记位为0，负载类型为8。
00 05：序列号，占用两个字节。
8f 21 4e c8：时间戳，占用四个字节。
a9 68 d2 ad：同步源（SSRC）标识符，占用四个字节。每个发送RTP数据包的同一个数据流都应具有相同的SSRC标识符，以便接收端可以区分来自不同数据流的数据

五、解析ps包

ps包的视频部分，IDR帧：
在这里插入图片描述
遇到IDR帧一般都要插入一个PSM包，所以可以通过找psm包判断有哪些I帧，
一帧太大了，需要分帧，第二帧在rtp包后面直接放数据即可

普通视频帧，e0表示是视频帧

数据解析

1、psh数据解析：
在这里插入图片描述
2、系统头解析： 00 00 01 bb 00 0c 80 cc f5 04 21 7f c0 c0 20 e0 e1 90
"00 00 01"开头的部分标识了PS数据流中的分组头（packet header），接着紧随其后的"bb"表示这是一个系统头（System Header）。
接下来的部分可以将数据按照具体字段进行解析：
“00 0c”：表示系统头的长度为12字节。（系统头的长度字段）根据多个博客显示系统头的具体信息不需要解析，根据长度跳过读取psm信息即可
“80”：表示系统头起始码，后面会跟比特率信息。。。
3、解析psm数据： 000001bc0028c20100167116697265616465722f6d656469612d736572766572000891c0000024e00000c6e2d207

“00 00 01bc”：表示这是一个PSM数据包，前缀固定为"00 00 01"，bc表示流ID，指示这是一个Program Stream Map。
“0028”：这表明接下来的字节长度为28字节，即后面的数据部分的长度为28个字节。
“71 16 69 72 65 61 72 62 2f 6d 65 64 69 61 2d 73 65 72 76 65 72”：这部分是ASCII编码，在解码后为"irearb/media-server"，可能是相关流的媒体服务器名称或者标识符。
“0008”：音频流的码率信息为8。
“91c0”：这一段可能包含音频流的其他信息，91表示g711u格式。
“0024”：这部分开始是视频流描述的信息，24表示h265。
4、解析pes数据包：

为什么需要rtp协议和ps协议，个人思考

为什么需要rtp协议：
1、为了提高实时流的质量：rtp信息中包含：时间戳和序列号，便于接收方设置接收缓冲区整理乱序的数据包，让解码器能处理组合好的数据包，同时如果延迟或者抖动过大，可以要求发送端提前发送数据，或者接收方进行抖动预测调整播放时间
2、负载区分，实时流，例如多人会议场景，有多个视频画面和多个音频声音需要混合，rtp协议标记了流的类型，来源，方便进行流的控制。
3、提高网络适应性，所以rtp协议是为了实时流场景诞生的强大协议，更多的解决网络问题，ps协议是为了将es流打包，方便解码的协议。
ps包时为了将es数据打包的协议，便于播放器工作

码流分析常见思路

网络抓包分析码流：

GB码流的抓包文件可以使用wireshark分析，传输码流的包文件可以被解析成rtp包或者udp/tcp包。

1、打开抓包文件,找到码流包

（下拉进度条，找到大量包大小为1400+的数据包，因为rtp流的包大小一般被设定为1400，udp包的上限为1500，一般rtp包设置为1400，加上各类数据头头不会超过1500），然后追踪这条流，就能看到2个ip的通信包（rtsp和rtcp数据）和数据包。

2、找寻完整码流该有的相关信息：

1、是否包含PSM数据：搜索：000001bc。
视频流每个IDR帧前都需要发送PSM数据包，此数据包的包头为000001bc。
2、是否发生sps和pps消息，sps和pps以0x 00 00 01或0x 00 00 00 01为起始码，可以作为码流发生也可以作为
sdp信息发送，不好判断，如果sps和pps作为码流传输，需要先发送此信息，第一帧码流通常数据量较小，且包含这个起始码
3、音频帧和视频帧是否正确被标记，
音频帧标记：000001c0 ，同时音频帧数据量可能较小包含音频帧的数据包一般不会超过1400字节，如果每个音频帧都为最大数据量，可能音视频标记错误
视频帧标记：000001e0，同时视频帧数据较大，经常出现视频帧标记后连续多个最大数据包的情况。
结合音视频帧标记的数量也能判断是否出现标记错误。
以上方法可以在视频完全播放不出来的时候做一个初步的分析

es文件分析码流

在去除网络流的各种包头后得到了ps流，这时，可以通过各种工具进行分析
1、wireshark打开，打开后能看到解析的各种包名，核对下是否符合ps流该有的数据结构：
在这里插入图片描述
从下面图可知，sys头，psm数据，音视频数据都在，若想手动分析，也可以将视频数据的二进制文件解析

手动解析找到帧类型的字符串，判断帧类型，判断是否有IDR帧：

解析音频数据和视频数据的pts信息，看有没有pts标记跳跃太大，导致音视频同步错误等等。
2、vlc播放视频，观察视频是否能正确播放。
3、使用FFMPeg播放视频，并一点点调试发现视频问题。