培训-GB28181中的视频流.doc

浅论GB28181平台视频流

武汉烽火众智数字技术有限责任公司

目录
一、 概述 3
二、 国标媒体流简介 3
2.1视频流的数据要求 3
2.2视频流编解码要求 4
2.2.1基于H.264的视频编、解码技术要求 4
2.2.2基于MPEG-4的视频编/、解码技术要求 6
2.2.3 SIP信令中的SDP内容规范 8
2. 3国标视频流示例 10
三、 实际问题浅析 12
3.1 客户端解码花屏 12
3.2 解码器无法解码 14
3.3 画面出现卡顿 17
四、 小论总结 18
4.1码流的不确定性 18
4.2以国标为本 19

一、 概述
GB/T 28181-2011是2011年由中华人民共和国公安部提出，中国国家标准化管理委员会发布的国家标准。
GB/T 28181-2011的正式实施规定了安全防范影像视频监控联网系统中信息传输、交换、控制的互联结构、通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、传输流程和协议接口等技术要求。适用于安全防范视频监控联网系统及城市监控报警联网系统的方案设计、系统检测、验收以及与之相关的设备研发、生产。
虽然该标准不可能一次性解决视频监控联网系统中的所有技术规定，但是比较清晰地定义了建议的通讯模型，重要的数据格式，和既有系统的兼容性方案，以及子系统和外部系统之间的通讯模式。对大型系统建设，尤其是联网的社会共享性系统建设给出了明确的、可实施的技术标准。
本文主要结合贵州省国标平台项目的实施经验介绍并讨论GB/T 28181-2011中媒体流相关知识。
二、 国标媒体流简介
下面通过GB28181-2011中的媒体传输和编解码协议两方面，简单介绍下国标对媒体流的技术要求本节内容部分引用GB/T28181-2011中4.3.6小节、附录C、附录E、附录F。
：
2.1视频流的数据要求
GB/T 28181-2011中规定媒体流在联网系统IP网络上传输时应采用RFC 3550规定的RTP协议，提供实时数据传输中的时间戳信息及各数据流的同步；应采用RFC 3550规定的RTCP协议，为按序传输数据包提供可靠保证，提供流量控制和拥塞控制。
RTP的负载应采用如下两种格式之一：
1.基于PS封装的视音频数据
基于RTP的PS封装首先按照ISO/IEC 13818-1:2000将视音频流封装成PS包，再将PS包以负载的方式封装成RTP包。PS包的主要参数设置针对本文档规定的几种视音频格式，PS包中的流类型（stream_type）的取值如下：
a) MPEG-4视频流：0x10；
b) H.264视频流：0x1B；
c) SVAC视频流：0x80；
d) G.711音频流：0x90；
e) G.722.1音频流：0x92；
f) G.723.1音频流：0x93；
g) G.729音频流：0x99；
h) SVAC音频流：0x9B。
PS包的RTP封装格式参照RFC2250，RTP的主要参数设置如下：
a) 负载类型（payload type）:96；
b) 编码名称（encoding name）：PS；
c) 时钟频率（clock rate）：90kHz；
d) SDP描述中“m”字段的“media”项：video。

2.基于RTP的视音频基本流封装
该方式直接将视音频数据以负载的方式封装成RTP包。
A）MPEG-4视频流的RTP封装
MPEG-4视频流的RTP封装格式应符合RFC3016协议中的相关规定。
MPEG-4视频流RTP包的负载类型（Payload Type）标识号选定：从RFC3551协议的表5中的动态范围（96-127）中选择,建议定为97。
B）H.264视频流的RTP封装
H.264的RTP载荷格式应符合RFC3984中的相关规定。
H.264视频流RTP包的负载类型（Payload Type）标识号选定：从RFC3551协议的表5中的动态范围（96-127）中选择,建议定为98。
C）SVAC视频流的RTP封装
SVAC视频流的RTP载荷格式可参照RFC3984中的相关规定。
SVAC视频流RTP包的负载类型（Payload Type）标识号选定：从RFC3551协议的表5中的动态范围（96-127）中选择,建议定为99。

2.2视频流编解码要求
联网系统中，对视音频编/解码的技术要求包括编/解码的档次和级别、工具选项、码流语法的规定以及比特流和解码器的一致性测试等。具体要求如下：
视频编码应支持H.264、SVAC或 MPEG-4视频编码标准，视频解码应同时支持H.264、SVAC和 MPEG-4视频解码标准。
2.2.1基于H.264的视频编、解码技术要求
2.2.1.1 H.264的档次和级别
采用H.264标准的视频编码应至少支持ITU-T Rec. H.264-2005视频标准的基本档次（Baseline Profile），级别（Level）应至少支持到Level 1.3，标清应用宜扩展支持到Level 3，高清应用宜扩展支持到Level 4；视频解码所支持的档次和级别应不低于编码支持的最高档次和级别，至少应支持到H.264视频标准基本档次的Level 3；视频解码宜扩展支持H.264主档次（Main Profile）中的隔行扫描和B帧工具，且相邻两P帧间的B帧个数不大于2。
1、H.264基本档次的选项和工具
H.264基本档次支持的选项和工具主要有：
a) I片和P片（Slice）；
b) 基于内容自适应的变长编码CAVLC；
c) 容错工具：FMO，ASO，RS；
d) 去块效应滤波器（Deblocking Filter）；
e) 多参考帧编码。
采用H.264编码标准的视频流应为H.264 Baseline视频流，编码应支持上述Baseline选项和工具中的部分或全部，可不支持容错工具；H.264的解码至少应支持上述除容错工具外的全部选项和工具。
多参考帧编码时，P片的参考帧数一般不大于两帧。
为了保证码流解析的效率，比特流中应当在每个I 帧之前都出现相应的SPS 和PPS；
2、H.264级别的限制
H.264级别（Level 1～4）的限制如表1所示， 表中“-”表示未做相应的限制。

表1 H.264级别（Level 1～4）的限制
级别
最大宏块处理速率
MaxMBPS
(宏块数/秒)
最大帧尺寸
MaxFS
(宏块数)
最大解码图像缓冲区
MaxDPB
(4:2:0视频以1024字节为单位)
最大视频比特率
MaxBR
(1000bits/s 或1200bits/s)
最大编码图像缓冲区MaxCPB
(1000 bits 或1200bits)
垂直运动矢量构成范围
MaxVmvR
(亮度帧采样)
最小压缩比率
MinCR
两个连续宏块的最大运动矢量数
MaxMvsPer2Mb
1
1 485
99
148.5
64
175
[-64,+63.75]
2
-
1.1
3 000
396
337.5
192
500
[-128,+127.75]
2
-
1.2
6 000
396
891.0
384
1 000
[-128,+127.75]
2
-
1.3
11 880
396
891.0
768
2 000
[-128,+127.75]
2
-
2
11 880
396
891.0
2 000
2 000
[-128,+127.75]
2
-
2.1
19 800
792
1 782.0
4 000
4 000
[-256,+255.75]
2
-
2.2
20 250
1 620
3 037.5
4 000
4 000
[-256,+255.75]
2
-
3
40 500
1 620
3 037.5
10 000
10 000
[-256,+255.75]
2
32
3.1
108 000
3 600
6 750.0
14 000
14 000
[-512,+511.75]
4
16
3.2
216 000
5 120
7 680.0
20 000
20 000
[-512,+511.75]
4
16
4
245 760
8 192
12 288.0
20 000
25 000
[-512,+511.75]
4
16
注：“-”表示未做相应的限制。

3、H.264基本档次各级别的参数限制
H.264基本档次各级别的参数限制如表2所示。
表2 H.264基本档次各级别的参数限制
级别
最大子宏块尺寸（采样点数）
1
576
1.1
576
1.2
576
1.3
576
2
576
2.1
576
2.2
576
3
576
3.1
-
3.2
-
4
-

4、H.264各级别的最大帧率限制
H.264中CIF、4CIF、720p HD、1080p HD各级别（Level）的最大帧率限制如表3所示，表中的“-”表示未做相应的限制。其他分辨率各级别的最大帧率限制见ITU-T Rec. H.264-2005中的规定。
表3 H.264各级别的最大帧率限制
级别
最大帧尺寸
(宏块)
最大宏块速率
（宏块数/秒）
最大帧尺寸
（采样点数）
最大采样率（样点/秒）
格式
CIF
4CIF
720p HD
1080p HD

亮度宽度
352
704
720
1088

亮度高度
288
576
1280
1920

总宏块数
396
1584
3600
8160

亮度采样点数
101 376
405 504
921600
2088960
1
99
1485
25 344
380 160
-
-
-

1b
99
1485
25 344
380 160
-
-
-

1.1
396
3000
101 376
768 000
-
7.6
-

1.2
396
6000
101 376
1 536 000
-
15.2
-

1.3
396
11880
101 376
3 041 280
-
30.0
-

2
396
11880
101 376
3 041 280
-
30.0
-

2.1
792
19800
202 752
5 068 800
-
50.0
-

2.2
1620
20250
414 720
5 184 000

51.1
12.8

3
1620
40500
414 720
10 368 000
-
102.3
25.6

3.1
3600
108000
921600
27648000

172.0
68.2
30.0

3.2
5120
216000
1310720
55296000

172.0
136.4
60.0

4
8192
245760
2097152
62914560

172.0
155.2
68.3
30.1
注：“-”表示未做相应的限制。

2.2.2基于MPEG-4的视频编/、解码技术要求
2.2.2.1MPEG-4的档次和级别
采用MPEG-4标准的视频编码应至少支持ISO/IEC 14496-2:2004中简单档次（Simple Profile）的级别L5（ISO/IEC 14496-2:2004/Amd.2:2005），即MPEG-4 SP@L5。采用MPEG-4标准的视频解码所支持的档次和级别不应低于编码支持的最高档次和级别，宜扩展支持MPEG-4先进简单档次（Advanced Simple Profile）中的隔行扫描和B帧工具。
1、MPEG-4简单档次的工具
MPEG-4简单档次的工具包括：
a) Basic：基本工具，又包括以下几种工具：
1) I-VOP：帧内编码的矩形视频对象平面，逐行扫描的视频格式；
2) P-VOP：帧间编码的矩形视频对象平面，逐行扫描的视频格式；
3) AC/DC Prediction：AC/DC预测；
4) 4-MV：每个宏块可以有4个运动矢量；
5) Unrestricted MV：不受限制的运动矢量。
b) Error Resilience：容错工具，又包括以下3种工具：
1) Slice Resynchronization：片重同步；
2) Data Partitioning：数据划分；
3) Reversible VLC：可逆的变长编码。
c) Short Header：短头工具。
MPEG-4视频编码应支持上述简单档次的部分或全部工具，可不支持容错和短头工具；视频解码至少应支持除容错工具外的简单档次的全部工具。
2、MPEG-4简单档次各级别的参数限制
MPEG-4视频编/、解码应至少支持简单档次的L5级别，参数限制如表4所示。简单档次其他各级别的参数限制见ISO/IEC 14496-2:2004及ISO/IEC 14496-2:2004/Amd.2:2005中的相关规定。
表4MPEG-4简单档次L2、L3、L5级别的参数限制
级别
L2
L3
L5
典型分辨率
CIF (352×288)
CIF (352×288)
720×576
最大对象数
4
4
4
每种类型的最大对象数
4个简单对象
4个简单对象
4个简单对象
最大唯一量化表
1
1
1
最大视频内容验证（VMV）缓冲区(宏块组)
792
792
3240
最大视频复杂度验证（VCV）缓冲区（宏块）
396
396
1620
视频复杂度验证（VCV）解码速率（宏块/秒）
5940
11880
40500
视频复杂度验证（VCV）边界宏块解码速率（宏块/秒）
不适用
不适用
不适用
最大视频缓冲验证（VBV）缓冲区总和(16 384 bits)
40
40
112
最大视频对象层（VOL）视频缓冲验证（VBV）缓冲区总和(16 384 bits)
40
40
112
最大视频包长度（bits）
4096
8192
16384
最大目标呈现尺寸（宏块数）
不适用
不适用
不适用
小波限制
不适用
不适用
不适用
最大比特率 (kbit/s)
128
384
8000
单对象最大增强层数
不适用
不适用
不适用

3、MPEG-4的码流语法
为实现联网系统中视频流的互通，采用MPEG-4标准的视频码流语法应符合ISO/IEC14496-2:2004中的规定。
MPEG-4中简单档次不同级别的相应标识码见表5（见ISO/IEC14496-2:2004中的表G-1和ISO/IEC 14496-2:2004/Amd.2:2005中的规定）。
表5 MPEG-4简单档次各级别的标识码
档次/级别
标识码
保留
00000000
简单档次/级别 1
00000001
简单档次/级别 2
00000010
简单档次/级别 3
00000011
简单档次/级别4a
00000100
简单档次/级别5
00000101
保留
00000110 − 00000111
简单档次/级别0
00001000

2.2.2.2 MPEG-4的一致性测试
包括比特流一致性测试和解码器的一致性测试。
l 比特流一致性测试
MPEG-4的一致性比特流（compliant bitstream）是指实现了ISO/IEC 14496-2:2004在通用语法中定义的所有限制的比特流，包括ISO/IEC 14496-2:2004中第9章关于档次和级别的限制。
MPEG-4的一致性比特流应满足如下测试：当使用解码软件对MPEG-4视频比特流进行解码时，不应出现任何由比特流引起的错误或不一致。
注：测试中不考虑由于传输而产生的错误。
MPEG-4的比特流一致性测试的附加测试见ISO/IEC 14496-4:2004中的描述。
上述验证比特流一致性用到的解码软件可参考ISO/IEC 14496-5:2001中指定的软件。
l 解码器的一致性测试
MPEG-4的视频解码器通常指某一特定档次和级别的解码器。
MPEG-4视频解码器的一致性测试见ISO/IEC 14496-4：2004中的规定，其中简单档次L5级别的视频解码器一致性测试见ISO/IEC 14496-4:2004/Amd.10:2005的规定。验证解码器一致性用到的软件可参考ISO/IEC14496-5:2001中指定的软件。
满足特定档次和级别的MPEG-4视频解码器应能正确解码相应档次和级别的MPEG-4一致性比特流。

2.2.3 SIP信令中的SDP内容规范
l SDP定义
联网系统中SIP消息体中携带的SDP内容应符合RFC 2327 - SDP Session Description Protocol的相关要求。应有如下字段：
Session description：
v= (protocol version)
o= (owner/creator and session identifier).
s= (session name)
u=* (URI of description)
c=* (connection information - not required if included in all media)
Time description：
t= (time the session is active)
Media description
m= (media name and transport address)
c=* (connection information - optional if included at session-level)
b=* (bandwidth information)
a=* (zero or more media attribute lines)
y=*（SSRC）
f=*（媒体描述）
说明：
a字段：启用RFC4566中对a字段的定义【a=rtpmap:<payload type><encoding name>/<clock rate> [/<encodingparameters>]中的<encoding name>，利用该属性携带编码器厂商名称（如：大华或海康编码名称DAHUA或HIKVISION）。该属性表明该流为某厂商编码器编码且是不符合本标准规定的媒体流，符合本标准规定的媒体流无需该属性。
例如：a=rtpmap:96DAHUA/90000；
a=rtpmap:96HIKVISION/90000。
s字段：使用s字段标识请求媒体流的操作类型。“Play”代表实时点播；“Playback”代表历史回放；“Download”代表文件下载。
u字段：u行应填写视音频文件的URI。该URI取值有两种方式：简捷方式和普通方式。简捷方式直接采用产生该历史媒体的媒体源（如某个摄像头）的设备ID（应符合6.1.2的规定）以及相关参数，参数用“：”分隔；普通方式采用http://存储设备ID[/文件夹]* /文件名，[/文件夹]*为0－N级文件夹。
t字段：当回放或下载时， t行值为开始时间和结束时间，用“”分隔，时间格式见RFC 4566的5.9，开始时间和结束时间均为要回放或下载的音视频文件录制时间段中的某个时刻。
y字段：为十进制整数字符串，表示SSRC值。格式如下：Dddddddddd（第一位为历史或实时媒体流的标识位，1为历史，0为实时）。
f字段： f = v/编码格式/分辨率/帧率/码率类型/码率大小a/编码格式/码率大小/采样率

以实际我司平台与其他平台对接过程中的SIP信令为例，下图中为我司与某厂家平台交互时请求实时视频的信令：

其中可以看出下方的SDP中m字段和a字段携带了3种编码方式，即国标中要求的PS流、H.264流和MEPG4流，这两个字段表明我司可以解码的3中形式，需要一提的是国标中也要求的SVAC（PT=99）视频流格式，主要用在部分ONVIF设备中，而大多数主流设备都没有按该方式编码，故我司没有做对该类码流的兼容。
S字段的值是“Play”表明该信令是请求实时点播。
2.3国标视频流示例
下面我们针对实际工程中遇见的码流来了解下在抓包时我们需要了解的只是，一般情况下我们在vtdu所在服务器或者CU客户端抓包，在Wireshark软件中打开，可以得到如下图所示的数据包：

此时对该数据按RTP协议方式查看，右键点击该包，按如下步骤操作：

操作完成后，数据包如下图所示：

现在我们可以看到从该包中已经可以显示传输方式，视频源，逻辑序号，和包的时间等参数了：
PT（payload type，负载类型）=96 即表示该视频流为2.1中的基于PS封装的音视频数据；
SSRC（Synchronization Source Identifier，同步源标示符）一般为32位，表示RTP包的起源，一般为源端随机分配的号码；
Seq（sequence number） 每发送一个 RTP 数据包，序列号增加1，表示该包在PS流中的逻辑序号；
Time（timestamp）反映了RTP数据包中的第一个比特组的采样时间，表示该包所在帧的时间，同一帧的时间应该一致。
值得注意的是，Seq=68的包末尾有一个Mark标示，该标示表示此帧为一个重要帧，下面我们打开该包来看看该标示的位置：

我们可以看见序号为68的包中RTP协议第5行为：1… …. = Marker ：True。该值为True的时候即为重要帧，此mark表示一般表示一个完整帧的数据边界。如下图：

序号为536的包是时间标志为101970的完整帧的结尾，而序号为537至539的三个数据包即可组成一个完整的数据包，在视频中即可组成一幅完整的画面。
另外，在国标中并没有对mark字段有详细的要求，但是目前我司CU或解码器解码的时候还是对会采用字段作参考。
国标中实际对一个完整帧的数据边界的定义在负载中，也就是除去前面这些包头后，真正组成一个画面的实际数据，如下图：

该包是该时间标示的所有包中的第一个，可看到该包中的payload负载部分的前6个字节是00 00 01，有这个前缀的包即表示一个完整帧的开始。
如果符合国标标准，所有表示一个完整帧的第一个包负载部分的首6个字节都应该是00 00 01。

三、 实际问题浅析
在上述两节中说明了国标对一些协议和字段的要求。
在贵州省平台项目中可以接触许多厂商的摄像机，虽然国标已经针对视频流定义了许多要求与协议，但是在实际对接中还是可以发现这些并不完善。
下面我们针对实际工程中遇到的一些问题作简单的分析：
3.1 客户端解码花屏
在对接过程中，因为我司已经兼容了大部分主流厂商，但是在实际工程中还是遇见实时视频解码出现问题的地方，比如在毕节七星关发现客户端解码华为的摄像机时出现了花屏的现象。
在VTDU上抓包分析后可以看出该包数据如下：

图1

图2
可以从第二幅图中看出Seq=42052的重要帧后的第一个帧的时间标识和该mark帧一样，而第一幅图中的mark帧后的第一帧与该mark帧的时间标识则不同。
以上两幅图中的数据是在同一数据包中，显然该mark标识的打法没有规律，但是我司解码的使用一般还是会参考该值，故由于在视频流中mark标识乱打的原因，平台在解码时还是会误认为mark前后为两个完整帧，即使两个帧有相同的时间标识，解码的时候还是会让着两个画面在同一时间显示出来，导致了花屏。
虽然此处对方的mark打法并没有不符合国标，但是我们依然要求了华为修改，未修改前播放视频时如下图：

在华为修改后如下图所示：

3.2 解码器无法解码
在贵州省毕节七星关有一个特别的现象，有一款摄像机，在平台客户端上的图像一切正常，但是却不能通过我司平台上墙。
在我司平台VTDU上抓包分析，并没有发现视频流有明显的问题，于是转而在信令上找答案，请求视频的流程同时在CMS上抓包。
在解释包之前，先说明下国标中第三方点播的流程：
a) 1：SIP服务器向媒体服务器发送Invite消息，此消息不携带SDP消息体；
b) 2：媒体服务器收到SIP服务器的Invite请求后，回复200 OK响应，携带SDP消息体，消息体中描述了媒体服务器接收媒体流的IP、端口、媒体格式等内容；
c) 3：SIP服务器收到媒体服务器返回的200 OK响应后，向媒体流发送者发送Invite请求，请求中携带消息2中媒体服务器回复的200 OK响应消息体，并且修改s字段为“Play”代表实时点播，增加y字段描述SSRC值，f字段描述媒体参数；
d) 4：媒体流发送者收到SIP服务器的Invite请求后，回复200 OK响应，携带SDP消息体，消息体中描述了媒体流发送者发送媒体流的IP、端口、媒体格式、SSRC字段等内容；
e) 5：SIP服务器收到媒体流发送者返回的200 OK响应后，向媒体服务器发送ACK请求，请求中携带消息4中媒体流发送者回复的200 OK响应消息体，完成与媒体服务器的Invite会话建立过程；
f) 6：SIP服务器收到媒体流发送者返回的200 OK响应后，向媒体流发送者发送ACK请求，请求中不携带消息体，完成与媒体流发送者的Invite会话建立过程；
g) 7：SIP服务器向媒体流接收者发送Invite消息，此消息不携带SDP消息体；
h) 8：媒体流接收者收到SIP服务器的Invite请求后，回复200 OK响应，携带SDP消息体，消息体中描述了媒体流接收者接收媒体流的IP、端口、媒体格式等内容；
i) 9：SIP服务器收到媒体流接收者返回的200 OK响应后，向媒体服务器发送Invite请求，请求中携带消息8中媒体流接收者回复的200 OK响应消息体，并且并且修改s字段为“Play”代表实时点播，增加y字段描述SSRC值；
j) 10：媒体服务器收到SIP服务器的Invite请求后，回复200 OK响应，携带SDP消息体，消息体中描述了媒体服务器发送媒体流的IP、端口、媒体格式、SSRC字段等内容；
k) 11：SIP服务器收到媒体服务器返回的200 OK响应后，向媒体流接收者发送ACK请求，请求中携带消息10中媒体服务器回复的200 OK响应消息体，完成与媒体流接收者的Invite会话建立过程；
l) 12：SIP服务器收到媒体服务器返回的200 OK响应后，向媒体服务器发送ACK请求，请求中不携带消息体，完成与媒体服务器的Invite会话建立过程；
m) 13：SIP服务器向媒体流接收者发送BYE消息，断开消息7、8、11建立的同媒体流接收者的Invite会话；
n) 14：媒体流接收者收到BYE消息后回复200 OK响应，会话断开；
o) 15：SIP服务器向媒体服务器发送BYE消息，断开消息9、10、12建立的同媒体服务器的Invite会话；
p) 16：媒体服务器收到BYE消息后回复200 OK响应，会话断开；
q) 17：SIP服务器向媒体服务器发送BYE消息，断开消息1、2、5建立的同媒体服务器的Invite会话；
r) 18：媒体服务器收到BYE消息后回复200 OK响应，会话断开；
s) 19：SIP服务器向媒体流发送者发送BYE消息，断开消息3、4、6建立的同媒体流发送者的Invite会话；
t) 20：媒体流发送者收到BYE消息后回复200 OK响应，会话断开。

在本问题中最重要的是流程3、4、6。由在CMS中所抓的包分析可得：
流程3：

流程4：

流程6

可以看到当CMS向前端发起INVITE请求时，前端设备回复的m字段中显示98、96两种方式解码，即前端告诉中心管理服务器，PS流和H.264流解码都可以。
而CMS将会把前端告诉它的消息原样告诉解码器，我们再来看看承担这个转述任务的流程11：

这是CMS告诉解码器的信息，m字段里面是转述的前端的解码要求，96或者98。
这就是原因所在，虽然前端给VTDU的是正常的PS流，但是信令中却说明96或者98都可以解码。客户端在解码时会自动去检测码流，然后按正常的方式解码，所以无法发现该前端的信令问题。而解码在接受到两种方式解码要求时，是不会也无法判断码流的，它只能无法分清应该用PS流还是H.264流的方式来解码，所以即使码流传输到了解码器，解码器也不会去解码。（以上主要是针对硬件解码器，我司解码器是软解码，也会对传输过来的码流进行判断）

3.3 画面出现卡顿
在平台建设过程中，总会有各种各样的情况出现，而视频卡顿总是一个监控平台极易出现的问题，有时我们会发现网页浏览的时候前端画面质量良好，但是使用平台观看的时候就会有卡顿现象。相信很多人都清楚使用网页浏览时使用的是TCP传输方式，而国标平台一般都是UDP的传输方式，传输质量总会比TCP的要差些。那么我们如何在视频包中发现这个问题呢？
下面是对以个产生卡顿的前端摄像机的在VTDU上抓包分析：

如上图所示，我们看见在序号为Seq=63589 与Seq=63590之间穿插了Seq=63486至64489等4个数据包，而且其中还有重要帧，最主要是Seq-63486的Payload中还有作为一个起始包的标识：00 00 01：
我们在回头看看4个包本来应该在的位置：

他们直接从之前丢失了，然后“流窜”到了后面的包中，而且这些流窜的包，恰好组成了一个完整的帧。
而从若直接在相机端抓包，则可以看出相机发出包时该4个包所在的地方并没有乱序。故必然是在前端发送到VTDU的过程中丢失了包，由此可证明网络确实存在问题。
在这个包中，还发现很多和上面现象一样的地方：

一次掉包后，在掉包和包重新到达而乱序的地方都需要重新寻找起始包来组帧，故造成了图像的卡顿。

四、 小论总结
在国标平台中视频流方面还有许多值得思考的问题，在与研发同事、各厂家技术人员的沟通和各类资料的学习中，总结以下几点针对工程人员的经验：
4.1码流的不确定性
国标平台虽然未能完善规定视频流的组帧方式，导致了不同厂家对视频流的不同理解，但是也严格的定义了流的编码格式和传输方式。
到目前为止，在贵州项目中遇到的所有厂商设备都可以输出画面，只是部分有花屏、半屏（只能显示一半画面）的现象。
如果是各类厂家的组帧方式影响视频解码质量的问题，研发同事可以通过查看码流的抓包即可修改我司的客户端以适应，并不需要增加解码库。同时也可以要求该厂家修改组帧方式以我们客户端适应的标准。但是严格上来说，并不能说其他厂家不符合国标。
4.2以国标为本
国标最为重要的还是国标本身，许多内容在国标中都有说明，在实际工作中还是会发现有些厂家的研发人员都没有认真的去阅读GB/T 28181-2011，导致做出来的产品有所纰漏。
最主要是工程技术人员遇见平台问题时，不应一味的抓包，然后交给研发处理，却不过问原因，而应首先在现场冷静分析问题所在的业务流程，逐项去分析，找准主要问题所在，再专业准确的向研发同事阐述清问题。

参考文献
[1] RFC 3550 RTP:实时应用程序传输协议
[2]RFC 3984 H.264视频的RTP负载格式
[3] RFC 2250 MPEG视频的RTP负载格式
[4] RFC 3016 MPEG-4 音视频的RTP负载格式
[5]GB/T 28181-2011
21 / 21 等级：四级