培训-GB28181中的视频流.docx

浅论GB28181平台视频流武汉烽火众智数字技术有限责任公司目录一、概述3二、国标媒体流简介32.1视频流的数据要求32.2视频流编解码要求42.2.1基于H.264的视频编、解码技术要求42.2.2基于MPEG-4的视频编/、解码技术要求62.2.3 SIP信令中的SDP内容规范82. 3国标视频流示例10三、实际问题浅析123.1 客户端解码花屏123.2 解码器无法解码143.3 画面出现卡顿17四、小论总结184.1码流的不确定性184.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的视频编、解码技术要求 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 14）的限制如表1所示， 表中“-”表示未做相应的限制。表1 H.264级别（Level 14）的限制级别最大宏块处理速率MaxMBPS(宏块数/秒)最大帧尺寸MaxFS(宏块数)最大解码图像缓冲区MaxDPB(4:2:0视频以1024字节为单位)最大视频比特率 MaxBR(1000bits/s 或1200bits/s)最大编码图像缓冲区MaxCPB(1000 bits 或1200bits)垂直运动矢量构成范围MaxVmvR(亮度帧采样)最小压缩比率MinCR两个连续宏块的最大运动矢量数MaxMvsPer2Mb11 48599148.564175-64,+63.752-1.13 000396337.5192500-128,+127.752-1.26 000396891.03841 000-128,+127.752-1.311 880396891.07682 000-128,+127.752-211 880396891.02 0002 000-128,+127.752-2.119 8007921 782.04 0004 000-256,+255.752-2.220 2501 6203 037.54 0004 000-256,+255.752-340 5001 6203 037.510 00010 000-256,+255.752323.1108 0003 6006 750.014 00014 000-512,+511.754163.2216 0005 1207 680.020 00020 000-512,+511.754164245 7608 19212 288.020 00025 000-512,+511.75416注：“-”表示未做相应的限制。3、H.264基本档次各级别的参数限制H.264基本档次各级别的参数限制如表2所示。表2 H.264基本档次各级别的参数限制级别最大子宏块尺寸（采样点数）15761.15761.25761.357625762.15762.257635763.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各级别的最大帧率限制级别最大帧尺寸(宏块)最大宏块速率（宏块数/秒）最大帧尺寸（采样点数）最大采样率（样点/秒）格式CIF4CIF720p HD1080p HD亮度宽度3527047201088亮度高度28857612801920总宏块数396158436008160亮度采样点数101 376405 5049216002088960199148525 344380 160-1b99148525 344380 160-1376768 000-7.6-1.23966000101 3761 536 000-15.2-1.339611880101 3763 041 280-30.0-239611880101 3763 041 280-30.0-2.179219800202 7525 068 800-50.0-2.2162020250414 7205 184 00051.112.83162040500414 72010 368 000-102.325.63.1360010800092160027648000172.068.230.03.25120216000131072055296000172.0136.460.048192245760209715262914560172.0155.268.330.1注：“-”表示未做相应的限制。2.2.2基于MPEG-4的视频编/、解码技术要求MPEG-4的档次和级别采用MPEG-4标准的视频编码应至少支持ISO/IEC 14496-2:2004中简单档次（Simple Profile）的级别L5（ISO/IEC 14496-2:2004/Amd.2:2005），即MPEG-4 SPL5。采用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 (352288)CIF (352288)720576最大对象数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 简单档次/级别4a00000100简单档次/级别500000101保留00000110 00000111简单档次/级别000001000 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 descriptionm= (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:/ /中的，利用该属性携带编码器厂商名称（如：大华或海康编码名称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/文件夹* /文件名，/文件夹*为0N级文件夹。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流的方式来解码，所以即使码流传输到了解码器，解