(完整版)培训-GB28181中的视频流

1、1 / 20等级：四级浅论GB28181平台视频流武汉烽火众智数字技术有限责任公司2 / 20等级：四级目录一、概述 . 4二、国标媒体流简介 . 42.1视频流的数据要求 . 42.2视频流编解码要求 . 52.2.1基于 H.264 的视频编、解码技术要求 . 52.2.2基于 MPEG-4 的视频编 /、解码技术要求 . 72.2.3 SIP 信令中的 SDP 内容规范 . 92. 3 国标视频流示例 . 11三、实际问题浅析 . 133.1客户端解码花屏 . 133.2解码器无法解码 . 153.3画面出现卡顿 . 183 / 20等级：四级四、小论总结 . 194.1 码流的不确定性

2、 . 194.2以国标为本 . 204 / 20等级：四级概述GB/T 28181-2011是2011年由中华人民共和国公安部提出，中国国家标准化管理委员会发布的国家标准。GB/T 28181-2011的正式实施规定了安全防范影像视频监控联网系统中信息传输、交换、控制的互联结构、通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、 传输流程和协议接口等技术要求。适用于安全防范视频监控联网系统及城市监控报警联网系 统的方案设计、系统检测、验收以及与之相关的设备研发、生产。虽然该标准不可能一次性解决视频监控联网系统中的所有技术规定，但是比较清晰地定义了建议的通讯模型，重要的数据格式，和

3、既有系统的兼容性方案，以及子系统和外部系统之间的通讯模式。对大型系统建设，尤其是联网的社会共享性系统建设给出了明确的、可实施的技术标准。本文主要结合贵州省国标平台项目的实施经验介绍并讨论GB/T 28181-2011中媒体流相关知识。二、国标媒体流简介下面通过GB28181-2011中的媒体传输和编解码协议两方面，简单介绍下国标对媒体流的技术要求I：2.1视频流的数据要求GB/T 28181-2011中规定媒体流在联网系统IP网络上传输时应采用 RFC 3550规定的RTP协议，提供实时数据传输中的时间戳信息及各数据流的同步；应采用RFC 3550规定的RTCP协议，为按序传输数据包提供可靠保

4、证，提供流量控制和拥塞控制。RTP的负载应采用如下两种格式之一：1基于PS封装的视音频数据基于RTP的PS封装首先按照ISO/IEC 13818-1:2000将视音频流封装成 PS包，再将 PS 包以负载的方式封装成RTP包。PS包的主要参数设置针对本文档规定的几种视音频格式，PS包中的流类型(stream_type )的取值如下：a)MPEG-视频流：0 x10 ；b)H.264 视频流：0 x1B;c)SVA觎频流：0 x80 ；d)G.711 音频流：0 x90 ；e)G.722.1 音频流：0 x92；f)G.723.1 音频流：0 x93；g)G.729音频流：0 x99 ；h)SV

5、ACT 频流：0 x9B。PS包的RTP封装格式参照 RFC225Q RTP的主要参数设置如下：I本节内容部分引用 GB/T28181-2011中4.3.6小节、附录 C、附录E、附录F5 / 20等级：四级a)负载类型( payload type ):96；b)编码名称( encoding name )： PS；c)时钟频率( clock rate )： 90kHz；d)SDP描述中m” 字段的media”项：video。2基于RTP的视音频基本流封装该方式直接将视音频数据以负载的方式封装成RTP包。A)MPEG-视频流的RTP封装MPEG-视频流的RTP寸装格式应符合RFC301眇议中的相

6、关规定。MPEG-视频流RT电的负载类型(Payload Type )标识号选定：从 RFC355协议的表5中 的动态范围( 96-127 )中选择 , 建议定为 97。B)H.264视频流的RTF封装H.264的RTF载荷格式应符合 RFC398仲的相关规定。H.264视频流RTP包的负载类型(Payload Type)标识号选定：从 RFC3551协议的表5中的 动态范围( 96-127)中选择 ,建议定为 98。C)SVA(视频流的RTF封装SVA(视频流的RTf载荷格式可参照RFC398仲的相关规定。SVA视频流RTP包的负载类型(Payload Type )标识号选定：从 RFC35

7、5协议的表5中的 动态范围( 96-127)中选择 ,建议定为 99。2.2 视频流编解码要求联网系统中， 对视音频编 /解码的技术要求包括编 /解码的档次和级别、 工具选项、 码流 语法的规定以及比特流和解码器的一致性测试等。具体要求如下：视频编码应支持 H.264、SVA(或MPEG-4视频编码标准，视频解码应同时支持 H.264、SVAC 和MPEG-4视频解码标准。2.2.1基于H.264的视频编、解码技术要求 H.264 的档次和级别采用 H.264 标准的视频编码应至少支持 ITU-T Rec. H.264-2005 视频标准的基本档次 (Baseline Profi

8、le )，级别( Level )应至少支持到 Level 1.3 ，标清应用宜扩展支持到 Level 3，高清应用宜扩展支持到Level 4 ；视频解码所支持的档次和级别应不低于编码支持的最高档次和级别，至少应支持到 H.264 视频标准基本档次的 Level 3 ；视频解码宜扩展支持H. 264主档次(Main Profile )中的隔行扫描和 B帧工具，且相邻两 P帧间的B帧个数不大 于 2。I、H.264 基本档次的选项和工具H.264 基本档次支持的选项和工具主要有：a)I 片和 P 片(Slice )；b)基于内容自适应的变长编码CAVLC；c)容错工具： FMO， ASO， RS；

9、d)去块效应滤波器( Deblocking Filter )；6 / 20等级：四级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）的限制级别最大宏块

10、 处理速率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-

11、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 0

12、0020 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-7 / 20等级：四级4-4、H.264各级别的最大帧率限制H.264中CIF、4CIF、720p HD 1080p HD各级别（Level ）的最大帧率限制如表 3所示,

13、表中的“-”表示未做相应的限制。其他分辨率各级别的最大帧率限制见ITU-T Rec.H.264-2005中的规定。表3 H.264各级别的最大帧率限制级别最大帧尺寸（宏块）最大宏块速率（宏块数/秒）最大帧 尺寸（采样点数）最大采样 率（样点/ 秒）格式CIF4CIF720pHD1080pHD亮度宽 度3527047201088亮度高度28857612801920总宏块 数396158436008160亮度采 样点数101 376405 5049216002088960199148525 344380 160-1b99148525 344380 160-1376768

14、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 72010368000-102.325.63.1360010800092160027648000172.068.230.03.25120216000131072055296000172.0136.460.04819224576

15、0209715262914560172.0155.268.330.1注：“-”表示未做相应的限制。2.2.2基于MPEG-4的视频编/、解码技术要求MPEG-4的档次和级别采用MPEG-4标准的视频编码应至少支持ISO/IEC 14496-2:2004中简单档次（SimpleProfile ）的级别 L5（ ISO/IEC 14496-2:2004/Amd.2:2005），即 MPEG-4SPL5 采用 MPEG-4标准的视频解码所支持的档次和级别不应低于编码支持的最高档次和级别，宜扩展支持MPEG-4先进简单档次（Advaneed Simple Profile）中的隔行扫描和

16、B帧工具。1、MPEG-4简单档次的工具8 / 20等级：四级MPEG-4简单档次的工具包括：a） Basic :基本工具，又包括以下几种工具：1） I-VOP :帧内编码的矩形视频对象平面，逐行扫描的视频格式；2） P-VOP帧间编码的矩形视频对象平面，逐行扫描的视频格式；3） AC/DC Prediction : AC/D（预测；4） 4-MV：每个宏块可以有4个运动矢量；5） Un restricted MV :不受限制的运动矢量。b） Error Resilie nee:容错工具，又包括以下3种工具：1） Slice Resynchroni zati on:片重同步；2） Data P

17、artitio ning :数据划分；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级别的参数限制级别L

18、2L3L5典型分辨率CIF (352 288)CIF (352 88)720X576最大对象数444每种类型的最大对象数4个简单对象4个简单对象4个简单对象最大唯一量化表111最大视频内容验证（VMV ）缓冲区（宏块组）7927923240最大视频复杂度验证（VCV ）缓冲区（宏块）3963961620视频复杂度验证（VCV ）解码速率（宏块/秒）59401188040500视频复杂度验证（VCV ）边界宏块解码速率（宏块/秒）不适用不适用不适用最大视频缓冲验证（VBV ）缓冲区总和（16 384 bits）4040112最大视频对象层（VOL ）视频缓冲验证（VBV ）缓冲区总和（16 38

19、4 bits）4040112最大视频包长度（bits）4096819216384最大目标呈现尺寸（宏块数）不适用不适用不适用小波限制不适用不适用不适用最大比特率 （kbit/s）1283848000单对象最大增强层数不适用不适用不适用3、MPEG-4的码流语法为实现联网系统中视频流的互通，采用MPEG-标准的视频码流语法应符合ISO/IEC14496-2:2004 中的规定。MPEG-中简单档次不同级别的相应标识码见表5 （见ISO/IEC14496-2:2004中的表G-1和ISO/IEC 14496-2:2004/Amd.2:2005 中的规定）。9 / 20等级：四级表5 MPEG-4简

20、单档次各级别的标识码档次/级别标识码保留00000000简单档次/级别100000001简单档次/级别200000010简单档次/级别300000011简单档次/级别4a00000100简单档次/级别500000101保留00000110 - 000 00111简单档次/级别0000010002222 MPEG-4 的一致性测试包括比特流一致性测试和解码器的一致性测试。比特流一致性测试MPEG-4 的一致性比特流(complia nt bitstream )是指实现了 ISO/IEC 14496-2:2004 在通用语法中定义的所有限制的比特流，包括ISO/IEC 14496-2:2004 中

21、第9章关于档次和级别的限制。MPEG-4的一致性比特流应满足如下测试：当使用解码软件对 MPEG-4视频比特流进行解码时，不应出现任何由比特流引起的错误或不一致。注：测试中不考虑由于传输而产生的错误。MPEG-4的比特流一致性测试的附加测试见ISO/IEC 14496-4:2004 中的描述。上述验证比特流一致性用到的解码软件可参考ISO/IEC 14496-5:2001中指定的软件。解码器的一致性测试MPEG-4勺视频解码器通常指某一特定档次和级别的解码器。MPEG-视频解码器的一致性测试见ISO/IEC 14496-4 : 2004中的规定，其中简单档次 L5级别的视频解码器一致性测试见I

22、SO/IEC 14496-4:2004/Amd.10:2005 的规定。验证解码器一致性用到的软件可参考ISO/IEC14496-5:2001中指定的软件。满足特定档次和级别的 MPEG-视频解码器应能正确解码相应档次和级别的MPEG-一致性比特流。2.2.3 SIP信令中的SDP内容规范SDP定义联网系统中 SIP消息体中携带的 SDP内容应符合 RFC 2327 - SDP Session DescriptionProtocol的相关要求。应有如下字段 ：Session description：v= (protocol versi on)o= (ow ner/creator and ses

23、si on ide ntifier).s= (sessi on n ame)u=* (URI of descriptio n)c=* (connection information - not required if included in all media)Time description :10 / 20等级：四级t= (time the sessi on is active)Media descripti onm= (media n ame and tra nsport address)c=* (conn ecti on in formati on - opti onal if in

24、eluded at sessi on-level)b=* (ba ndwidth in formati on)a=* (zero or more media attribute lin es)y=* (SSRC)f=* (媒体描述)说明：a 字段：启用 RFC4566 中对 a 字段 的定义【a=rtpmap:/ /中的 ，利用该属性携带编码器厂 商名称(如:大华或海康编码名称DAHUA或HIKVISION )。该属性表明该流为某厂商编码器编码且是不符合本标准规定的媒体流，符合本标准规定的媒体流无需该属性。例如：a=rtpmap:96DAHUA/90000 ；a=rtpmap:96HIKVIS

25、ION/9OOOO。s字段：使用s字段标识请求媒体流的操作类型。“ Play”代表实时点播；“ Playback”代表历史回放；“ Download ”代表文件下载。u字段：u行应填写视音频文件的URI。该URI取值有两种方式：简捷方式和普通方式。简捷方式直接采用产生该历史媒体的媒体源(如某个摄像头)的设备ID (应符合6.1.2的规定)以及相关参数，参数用“：”分隔；普通方式采用http:/存储设备ID/ 文件夹* /文件名，/文件夹*为0 N级文件夹。t字段：当回放或下载时，t行值为开始时间和结束时间，用“”分隔，时间格式见RFC4566的5.9,开始时间和结束时间均为要回放或下载的音视频

26、文件录制时间段中的 某个时刻。y字段：为十进制整数字符串，表示 SSRC值。格式如下：Dddddddddd (第一位为历史或 实时媒体流的标识位，1为历史，0为实时)。f字段：f = v/编码格式/分辨率/帧率/码率类型/码率大小a/编码格式/码率大小/采样率以实际我司平台与其他平台对接过程中的SIP信令为例，下图中为我司与某厂家平台交互时请求实时视频的信令:IITE sip： 230100001311663&4 0172,16, k 221:5061 SIP 2.0 via; SIP/Z.0/UDP+rporti branch=i3hG4bKLC3B534B0Frcr:p：521000000

27、021537313223172,16.2.201rtaq=1434 5B4218To : : 5user-Aqerrt: mediasi p/2, 0Expires: 120Stbjtct 1 52230100001311fi6S&40:l,52100000002153731322:1Al 1 C-vi ： IN ITEt ACK, UPDATE t IrO t CANCEL t DYE1 OPTIONS , REFER, 5UD5CRIDE , NOTIFY, MFSSAGFCent err-Te： application sdpcontert-Length；245v-CO-521C0C0C

28、0021537n322 1234 56 0 IN IP4 172.16.2-201 s=PlayZP4 172,16.2.201t=0 0m=video 27034 RTPAVP 盹他 Q7a-rtprrar :96 PS/90000a-rTprrap ;5E H264/90000m=rTprrap ；97 MPEG4 9QOOO狂 _r ecor1 y11 / 20等级：四级f=v/2/5/25/l/2a；/；其中可以看出下方的 SDP中m字段和a字段携带了 3种编码方式，即国标中要求的PS流、H.264流和MEPG4流，这两个字段表明我司可以解码的 3中形式，需要一提的是国标 中也要求的S

29、VAC（ PT=99 ）视频流格式，主要用在部分 ONVIF设备中，而大多数主流设 备都没有按该方式编码，故我司没有做对该类码流的兼容。S字段的值是“ Play表明该信令是请求实时点播。2.3国标视频流示例F面我们针对实际工程中遇见的码流来了解下在抓包时我们需要了解的只是，一般情况下我们在vtdu所在服务器或者 CU客户端抓包，在Wireshark软件中打开，可以得到如下图所示的数据包:酣5.171h 16. J-JOOUJrlC.3, 17UPF1J54 souxc pXl :20120恥沉伽伽 porir dr|j&4b.172,16. 3. 2DO172.16-3.17UDP1223so

30、urcepori:20120Dsr1 iarlan par T t drp4. 5*00171.1*-3.17财187畫口 uh por t :2O12DGsiit indt T aii por t * dirp64 $2 巧4000172.16. ).?0Qi j筑監订UDP1014 Sairjrc*1par t:2OT.J0irfttigm port; drp氐曰抽BBCDQQ1T2.16, l.ZIQD17Z.1S, 3rl7UDP1X7-Soi-rctpot:2Q1JQon port; drp匕.172.1B. J.20D172.14 . K17UDFbotr口 ort ：sunDss

31、TiraLtioii ports： drp阿6 6977MDOO17UCF1354sou CtIMKl；2C-12Ocesiii ac Lon purl： dru706. 6G5Dr4DOD172.16.1.SOD172.16-3.17UDF1354sourcepori:.2 DI 2DDsr InaLlan porx t drp?1 6./O&SDaD172.16. JuDU6F1血par k :2CH.2DOrAt inaiC T ail par t i dirf此时对该数据按 RTP协议方式查看，右键点击该包，按如下步骤操作:Mark Packet (toggle)Ignore 匚Ice

32、t (toggle) 込)St Iim Rfrftrance toggle Time Shift,t.Edit cr Add PacIcet 匚orrimerrt.Manually Resolve AddressApply aw FilterPrepare a Filter匚onversation FilterColorize ConversationSCTPFollow TCP StreamFollow UDP StreamFollow SSL StreamCopy星 Decode As.工 Print“5IIQW Packet in New V/indow12 / 20等级：四级Real-

33、Time Transport Protioizo操作完成后，数据包如下图所示:71乩M时初RQL71.1A. i.smlrz-lfl- J.17RTFM PTfiywi1 CtTP-Ijrf列*CNh awnrr.耳4、九Tit-WQ72 17?. 16 . J.3MI?7H；TP:巧g P-cTnicfl-P-rr； T-b衣朗：-o打mm冲细=.iTTiw-59iO1.18.1-Mfl172x11. R17IIKJL hfl F -右 *G-isiK.-a-itwut纽尸口皿 fl.-ggjJ5PW173.1Qi9.QXT甌山J+17HTF13H FT-praniitftT

34、P-Tjqp4：-5H&a屏沪H Tr咻75P新17Z.lQi.i.3Mi72ai&.KrBtFUSJl FT=CTil1 CflHP黄1.t1t=W9FC I TUMI 1狂何Whm.n. i.i?Rl?ilM PT-C牌刊”-X.总吟斗fir陷77 D. HUJTIZWH17Z.1&.J.2WJ1 了為3rlT13Jdi FTKflniCTP-Type-5Sja( (jT3B9-JuZ9*i=1|5di.Tte-JD7K- bLlJt$lW)L7E.16. l.WR.TFIJH *Cpnjra1i：RTP 内*袴.9BKYWB 九wart； 7S 6.711E=BOOT172.1&.3.Z

35、OD172.IE. 3-17A1TP13E4 PT-Cyrarncn-P-rypi E-nFnITW-5MDBO E TUaWMIi?2.ie, J.I?mr*UM申制耐恤i弼.勾艸訂息牧榊tetjk-jMefit缶理離加两好# 越$期1-17HTF1154 PT-ih1 CHTF-iilie-6!匸羽-S-34DHl _ 1R7TP516 PT-DVirt1 CH.TP-Typ*-,6,I15F-Z辄凝 F filj-M：-3iD, M-ar k. i_nin.i a. KirITf1U7CftTP-Type-M.S*g_TPiw-llO现在我们可以看到从该包中已经可以显示传输方式，视频源，

36、逻辑序号，和包的时间等参数了：PT（ payload type，负载类型）=96即表示该视频流为 2.1中的基于PS封装的音视频数 据；SSRC（ Synchronization Source Identifier，同步源标示符）一般为 32 位，表示 RTP 包的 起源，一般为源端随机分配的号码；Seq （sequenee number）每发送一个 RTP数据包，序列号增加 1，表示该包在 PS流中 的逻辑序号；Time （timestamp）反映了 RTP数据包中的第一个比特组的采样时间，表示该包所在帧 的时间，同一帧的时间应该一致。值得注意的是，Seq=68的包末尾有一个 Mark标示，

37、该标示表示此帧为一个重要帧，下 面我们打开该包来看看该标示的位置:14- frM: 5JO byt殆 w 旷电(428 bits), 516 byte!. Cdptwred (4288 bits) cm Intei FMC U便 Eth?rni?T ii( srer icro-5r_ji9：a7:) ( DST : 0B.：60：6#：4f :dd：sh (ST6D：#：4f :dd：sb)internet Protcrwl Versior 4S srC; 00 (172,16,3,200). St; 7 (172.3,17)I U5T EMldjran

38、 PTQiCO 匸(fl.古C_： MHO fBOlW. PSt fwt： drip (ZOOOOO. * verslonirRFC 1439 version.6 Pactolrig? Flse.0 =Fxtf-nsierii： FaJ 宜*.Ri. OGM Cpnt r i but i in g source identifiers ccnjnt; 0 尸-barker ： TrueFa/lOAd typ : OyniSLiii CRT：? -Typ e - St (曲 ntmiOar: EETirwsxanp: 彌0j-u 一一U-一 二一一亠二i Li 二-n k 二 二一 - Xh.

39、fell. ih ifH-C JZ*h我们可以看见序号为 68的包中RTP协议第5行为：1. = Marker : True。该值为True的时候即为重要帧，此 mark表示一般表示一个完整帧的数据边界。如下图:13 / 20等级：四级1H自慎in idirj.jo. . ?ao1*?caT- TW *B.立XM ：1“： MW mwi1HS 0.1孔 in. i.zdDPT-Dyn*i1 cRTIP-T|pe-90,与沁-a*朋日削？芳丄,-eq-ftZgZT, Tlne-lzaHMCW, PurkZ3Z O.WITiDOlzz.ig. i. xa1192 FT-Dy-sni :ATP-Tj

40、iV*-Wi 百沁-0凉BTN声Scq-C2S0,211MEmLML*. 172.1*. BuJtiOfta- OP dm iLM 尸-yp-fi1 - W.17 P丽也驶1?2 16.3 IflO17Z. 16, J,l?f twUM FIsDnawl TW-1VUe-Mi 35=. P -D-, rani dfnrp- - /p-e - MBSiC-OK.ZiEAiLSFF, Seq-3,liae-lDLrya.Hark顶U? L-i- MOrmIII?irrF彌.Ti55J r 5i52CMB172.1fi.3.20D17. 1C. 1.17RTF1154 FTwnafll55ac=Jx

41、 i 牙牙 4- W -q=5i35n.mowcig7. W WlTLLl. I.14Di1141 PTCyiUiiiMWH 9W.Hdr k5E17 -g4332CKK177.1.G-1.24H3173- 1G. 1, 17GTPH 3= P_-Dp nam cflTP -Typ-s - K-.SiUf-ClxDuwZQff iTHd-iaBCiDQ?. b!ITiMi31.100U2- lfi. 1.17HTP1IM ”注DytisHkRA/e-iyp-叽5ACClxiKKU4Fte E,sqM丄.THD-iaocdRTF13 R P J齢 nfluni ETP-T*哄-亦TiBBUKCT

42、55(7.号沏50W1?2.16,3,200172 It. 1.171JM -p rsrwi cfi-ype-Wa.C-OKJi&LCStP.员q昭 ATrrwe-lOWW55?1? lfr-3- IW172-. 17注皆 卩-=叶加伽磚.“叶時勺勺K=o町服弄畀 髀护岀4.T1 mW 1 Q 闪00与沁 7. -JULJSJ1?2_16-3.20D172-16_ J.广HTPA3 i-4 FT-a-rnaaiS. 311彰彰 5 -T-Gffid-in&ODG序号为536的包是时间标志为 101970的完整帧的结尾，而序号为537至539的三个数据包即可组成一个完整的数据包，在视频中即可组成

43、一幅完整的画面。另外，在国标中并没有对 mark字段有详细的要求，但是目前我司CU或解码器解码的时候还是对会采用字段作参考。国标中实际对一个完整帧的数据边界的定义在负载中，也就是除去前面这些包头后，真正组成一个画面的实际数据，如下图：该包是该时间标示的所有包中的第一个，可看到该包中的payload负载部分的前6个字节是00 00 01,有这个前缀的包即表示一个完整帧的开始。如果符合国标标准，所有表示一个完整帧的第一个包负载部分的首6个字节都应该是00 00 01。三、实际冋题浅析在上述两节中说明了国标对一些协议和字段的要求。在贵州省平台项目中可以接触许多厂商的摄像机，虽然国标已经针对视频流定义

44、了许多要求与协议，但是在实际对接中还是可以发现这些并不完善。下面我们针对实际工程中遇到的一些问题作简单的分析：3.1客户端解码花屏在对接过程中，因为我司已经兼容了大部分主流厂商，但是在实际工程中还是遇见实时视频解码出现问题的地方， 比如在毕节七星关发现客户端解码华为的摄像机时出现了花屏的coco 1414 d d0 0 0 0 0 0 9 9 0 014 / 20等级：四级现象。在VTDU上抓包分析后可以看出该包数据如下:ffTP1110 ：P-Cvrjni rfTF 口戶 M sSeqilWi2014- 12.5320-37S3LJ嗥 5-1433RTFLLLG 4Tra

45、n CfiTP -Type-Seq=4L9Sfii lBe=456B61SsGWLS 12. SlZDltS2.1CA. U1,101.4.121RTWULD PT-DyranicfrTlP-Type-,塞RCNI加g*晖匚8,Ml币】右拜?0丹需讪討和RTFIUD PT血3 12.&19999S.iOfi. 5-143RTFLlin FI-DyraiiCETP-Type-9S,=SK-OI1E99FF ,S4-q-4194,厂bHEH師乂却I zm晤MU已RTPU10眇MkRTP rypi!-也 舌yc-Ox豪純期H.5?,W.UTPHid PM和kffrp巧眄st. SWMClF升SlqH

46、IZI% HHMUfiiMfiC27 12.f20-i25口诧.5.14352.1JDB-4.223RTF1110 Fr-DIKoiCRTP-irypfe-ae； SSHC-OsilEaACSFFjj- itfe-4 565150押址12.倔佝V.1W, 5,1-iiRTP1 -CvnKm-Type-., 5Sfi-fld(99rrb如皿耳幻.Trre*44MM,帕MM祖:畑52.109. 5.1* J抽1划：IW山2QS0 12.6fiW12前也1, 14 3魚血UHETFUU.0 FTDyfUn1CITP-irpfr-9g. 涎旳IZ沁:嚼FF.SO-42ai4. TlifP6时宜和2CB

47、1 12 MMli5Z.10B. 5.U3SZ.liOB.l.ZllRTPHID M=Dynkinni-1495. 5SK=XiB9K：W=Fa运=1刃5昇 TiT.e=Jr5102M1 12.I!O145M0&. 5.141221RTF1110 RirwAlCKl P -Type-仏 各N-J0K3IE=UU： FF.朋* HFITlliQ FTrnwClll-TVpr-Mii S9K*H9SMCFFI矶rd Titp-4Rml谍.5143J2.L0B -I.IZ3RTF1L10 FT=ftir icrrp-irt-9ff 55WC=Ox3E5W；3FFbeiF4ZD5-3 TTre=4Hi

48、f B54602M2a6B05?,1, 5.UJ1110 -Cynicm-irpe-g 交啦離Z罚诉TWE7隔村弹妁235412.2252. LU. 5.1Gy.mi.rnRTP1110 frTsDyMfflcHTP-Typt-9 $胡1 旳5(恥碱外F.站=*2D&0. TM-JM-. biUfl可以从第二幅图中看出 Seq=42052的重要帧后的第一个帧的时间标识和该mark帧一样,而第一幅图中的 mark帧后的第一帧与该 mark帧的时间标识则不同。以上两幅图中的数据是在同一数据包中，显然该mark标识的打法没有规律，但是我司解码的使用一般还是会参考该值，故由于在视频流中mark标识乱打

49、的原因，平台在解码时还是会误认为 mark前后为两个完整帧，即使两个帧有相同的时间标识，解码的时候还是会 让着两个画面在同一时间显示出来，导致了花屏。虽然此处对方的 mark打法并没有不符合国标，但是我们依然要求了华为修改，未修改 前播放视频时如下图：15 / 20等级：四级在华为修改后如下图所示:日期日期: :2013-05-6X40:19:45:在拱村三茁踣匚在拱村三茁踣匚3.2解码器无法解码在贵州省毕节七星关有一个特别的现象，有一款摄像机，在平台客户端上的图像一切正常，但是却不能通过我司平台上墙。在我司平台 VTDU上抓包分析，并没有发现视频流有明显的问题，于是转而在信令上 找答案，请求

50、视频的流程同时在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：媒体流发送者收

51、到 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消息

52、体；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消16 / 20等级：四级息体，消息体中描述了媒体服务器发送媒体流的IP、端口、媒体格式、SSRC字段等

53、内容；17 / 20等级：四级媒体流接收者7 In vite13 BYE14 200 OK111 In vitei1I11112 200 OK (with SDP)IIAjh13 In vite (with SDP)114 200 OK (SDP)r15 ACK (with SDP)i11-M1_w110 200 OK (SDP)4if.4r1lgl12 ACKi实时媒体流k)11: SIP服务器收到媒体服务器返回的200 OK响应后，向媒体流接收者发送ACK请求，请求中携带消息10中媒体服务器回复的 200 OK响应消息体，完成与媒体流接收者的Invite会话建立过程；l)12： SIP服务

54、器收到媒体服务器返回的200 OK响应后，向媒体服务器发送 ACK请求，请求中不携带消息体，完成与媒体服务器的Invite会话建立过程；m)13： SIP服务器向媒体流接收者发送 BYE消息，断开消息7、8、11建立的同媒体 流接收者的Invite会话；n)14：媒体流接收者收到BYE消息后回复200 OK响应，会话断开；0) 15： SIP服务器向媒体服务器发送BYE消息，断开消息9、10、12建立的同媒体服务器的Invite会话；p)16：媒体服务器收到 BYE消息后回复200 OK响应，会话断开；q)17： SIP服务器向媒体服务器发送BYE消息，断开消息1、2、5建立的同媒体服务器的I

55、nvite会话；r)18：媒体服务器收到 BYE消息后回复200 OK响应，会话断开；s)19： SIP服务器向媒体流发送者发送BYE消息，断开消息3、4、6建立的同媒体流发送者的Invite会话；t)20：媒体流发送者收到BYE消息后回复200 OK响应，会话断开。在本问题中最重要的是流程 3、4、6。由在CMS中所抓的包分析可得:媒体服务器SIP服务器200 OK (with SDP)15 BYEI16 200 OK17 BYE18 200 OK19 BYE |20 200 OK11 ACK (with SDP)媒体流发送者实时媒体流9 In vite (with SDP)18 / 20等

56、级：四级流程3：INVITE Sip：522431010013257392IOS.0.143:5060 SIP/2.0Vii： SIP/2. 0/UDP 52. IOS. 5,13S : 5060; rport: branch-zghG4bK121701 斗石J18From: ;tag-i1S0676111TO： call-ID； 03867952,1Q&, 5.lSCSeq: 20 INVITECorracr: ip:522010100200706932252.LOS. 5.128:S060Max-Forwards: 5usi -Aeni: nedloExpires; 120subject:

57、 522401010013257BJ264 :1,5224010100114338745G；1Al 1 OW T ZINVITE ftCKj UPDATE * JNFO CANCEL , EYE f OPTIOMS * REFER. SUBSCRIBE t NOTIFY, MESSAGECuiittjrit-Type ; dppl icdt. ioii/idpcontent-Lenqth:224v=C0=52240101004005413426 123456 0 IN JP4 52,100.5,1S7s=P1 ayC=1M IP4 52.10&. 5.IS?t-0 0m-video ?97fi

58、4 RTP/AVP 9S 97 a=rTpmap:96 P5/90C00 a-rXprnap ; 98 H2 64 /SOODO a=rtpmap;97 MPEG4 ODOC a=recvonly y=099993999流程4:SLP/2.0 200 OKVi a:a: STP/Z. 0/UDP 52.52.108. 5.138:5060：rport：branch=z9hG4bK12170 3468S From: ;tag=4e0676111TO! ：tag-145524CS Call-ID： 36038679a38Geq： 20 INVITEcorn act !5lp：

59、52240101001327607327&52.108. 80-143 ! 5060user-Agent: SIP . NET 1.0 evolution versioncantent-Type: application/sdpcont ent-Length:220v-00-52240101001327507327 0 0 IN IP4 52.108.SO-H3s-PlAyC=IN IP4 43t-0 0m-vi dGO 29761 RTP/AVP 9& 96a-rtpniap: 96 PS/90000 a=sendonlya=sendonly a-iisername;

60、52240101001327607327a=password:1234Sy=Q99999999y=Q99999999流程6ACK sip:5224010100132760732752.108_108_ 80-143:5060 SIP/2SIP/2 0vi a: SIP/2. 0/UDP 52.108. 5-138： 5060; rporr; branch=:z9his4bK124：L65：L22却 From: ;taq=4fi0676111 To: ;tag=145524066 Cal 1-ID： 16O3867QS(&52.108. 5. 138C5eq: ZQ ACK contact； M