官方网站如何建立,做旅游网站毕业设计,wordpress ie6主题,宣传营销方式有哪些一、前言 某项目中需要集成视频管理平台#xff0c;实现分布在各省公司的摄像及接入#xff0c;对视频进行统一管理。本项目中视频管理平台采用GB/T28181实现的监控设备接入管理平台#xff0c;支持在开放互联网和局域网对监控设备进行远程接入、远程管理、远程调阅、录像回…一、前言 某项目中需要集成视频管理平台实现分布在各省公司的摄像及接入对视频进行统一管理。本项目中视频管理平台采用GB/T28181实现的监控设备接入管理平台支持在开放互联网和局域网对监控设备进行远程接入、远程管理、远程调阅、录像回看等功能。本文对此记录GB/T28181协议的原理和一些问题以供后续参考。
相关资源Nginx支持flv和mp4格式文件同时支持Rtmp协议同时打开rtmp的hls功能
二、视频协议
2.1、相关术语
1H265/H264视频编码 H.265又称为High Efficiency Video Coding (HEVC)是H.264的后继者同样由VCEG和MPEG联合开发。H.265的目标是在H.264的基础上进一步提高压缩效率理论上可以比H.264节省大约50%的比特率同时保持相同的视频质量。相对于H.264它能提供更大的编码单元CU尺寸从64×64到8×8像素的自适应四叉树结构改进了运动预测和帧内预测支持更高效的熵编码方法和更精细的量化参数控制。这些改进使得H.265在处理高清和超高清视频时更加高效但同时也意味着更高的计算复杂度可能影响到实时编码和解码的性能。基于H.265的高效性它更适合在高清和4K视频的流媒体和存储领域 \H.264*全称MPEG-4 Part 10或Advanced Video Coding (AVC)是由ITU-T的视频编码专家组VCEG和ISO/IEC的动态图像专家组MPEG联合开发的一种视频编码标准。H.264的主要目标是在与早期标准如MPEG-2和MPEG-4 Part 2相同的视频质量下提供大约两倍的压缩效率。这意味着使用H.264编码的视频文件可以比使用旧标准编码的文件小一半左右这对于网络传输和存储来说非常重要。通过块运动补偿预测、变换编码、熵编码如CABAC或CAVLC等多种技术实现了高效压缩。对于与265的区别首先H264/H265都是视频压缩标准但265会比264更先进一般能将文件大小压缩后比264再降低约50%以上可在相同质量下使用更低的码率即H.265在相同码率下可以提供更高的视频质量而264相对于一些老设备更具兼容性因H.265是较新的压缩标准不是所有的设备和平台都支持相比H.264是更为广泛支持的标准在包括手机、电视、电脑等多个平台上广泛应用故一般取H.264即可。NALUNetwork Abstraction Layer Unit是NAL层的基本数据单位由一个头部一个字节和一个负载部分组成其中头部包含了控制信息用于指示NAL单元的类型、重要性等级以及其他相关参数负载部分包含了实际的编码数据如图像数据、参数集数据等而负载数据的结构和内容取决于NAL单元的类型。 2输出HTTP-FLV、HTTP-MP4HTTP-FLV将音视频数据封装成 FLV格式文件然后通过 HTTP 协议传输给客户端。它具有低延迟特定内容延迟可以做到 2-5 秒只要浏览器支持 FlashPlayer 就能简易的播放它的地址是http://开头的是基于HTTP协议的可以简单地理解为RTMP的HTTP协议版本功能和工作原理是相似的且RTMP切片数据功能HTTP-FLV也是支持的但HTTP-FLV协议一般只能用作拉流观看。实际体验中 HTTP-FLV延迟会略高于RTMP但是HTTP-FLV相对RTMP适配更多的播放场景。Nginx中已经集成 nginx-http-flv-module支持该协议Nginx的HTTP-FLV插件是包含RTMP功能的所以一般HTTP-FLV的流媒体服务推流是以RTMP协议拉流是用HTTP-FLV协议。综上目前比较流行的方案是直播源推流是RTMP协议直播拉流观看是HTTP-FLV协议。HTTP-MP4基于HTTP的MP4协议将音视频数据封装成封装成mp4格式。MP4 文件的数据都是封装在一个又一个名为 Box 的单元中。一个 MP4 文件由若干个 Box/FullBox 组成每个 Box 包含了 Header 和 Data。所有的Metadata媒体描述元数据包括定义媒体的排列和时间信息的数据都包含在这样的一些结构box中。Metadata 对媒体数据比如视频帧引用说明而媒体数据在这些引用文件中的排列关系全部在第一个主文件中的metadata描述这样就会导致视频时长越大文件头就会越大、加载越慢。 4K流媒体代表(40962160分辨率)8K流媒体高清代表(81924320分辨率)720P(1280*720分辨率) 1080P(1920 * 1080分辨率)RTMPRTMP协议是既可以推流、也可以拉流的协议。RTMP和HTTP-FLV都是建立在FLV封装之上的RTMP一般用作直播源推流HTTP-FLV一般用作直播观看RTMP地址是rtmp://开头的且推流地址与播放地址是一样的。相对于HTTP方式很多防火墙会墙掉 RTMP但是一般不会墙 HTTP因此 HTTP FLV 出现奇怪问题的概率会很小FLV 是最简单的流媒体封装HTTP 是最广泛的协议这两个组合在一起维护性更高比 简单很多。RTMP通信是建立在TCP长连接通道上的在封装音视频数据时会强制切片限制每个数据包的大小这在一定程度保证了实时性有一定的弱网抵抗能力因为每个数据包都不会太大所以当某个数据包校验失败时重新发送的成本不会太大但也由于合并数据包会加大CPU压力所以是有一定的性能消耗的。RTMP具备低延迟内容延迟可以做到 2-5 秒。 \WebRTC是一种点对点的视频/语音通话协议。由于WebRTC是基于UDP的建立通信后会不断以流式发送数据所以延迟会比RTMP还要低。在一些交互性较高的直播场景如直播带货等场景会使用WebRTC作为推流和观看协议 WebRTC的延迟理论上可以达到1秒内。WebRTC协议支持推流和拉流地址一般是以webrtc://开头的且推流和拉流地址一般是一样的。WebRTC虽然是点对点的协议但是应用在直播场景的话是需要搭建WebRTC服务器作为流媒体服务的流媒体服务软件可以使用SRSSRS是国内研发的一个比较流行的开源流媒体服务软件目前4.0已经囊括了RTMP、HLS、WebRTC、HTTP-FLV等主流协议。 \RTSP/Onvif协议一般不用作直播场景RTSP一般用作摄像头、监控等硬件设备的实时视频流观看与推送上。尽管RTSP协议也支持推流/拉流且支持TCP、UDP切换以及其他诸多优点。但是泛用性不足特别是现在的浏览器都不支持RTSP的播放。RTMP 和 RTSP 都是流媒体传输协议它们之间的主要区别1RTMP 是一种基于 TCP 的实时传输协议而 RTSP 是一种基于 UDP 的实时传输协议。2传输方式RTMP 是一种单向传输协议信息只能从服务器端传输到客户端。而 RTSP 支持双向传输允许服务器端和客户端之间进行实时通信。3控制协议RTSP 是一种控制协议它可以用于控制媒体流的播放、暂停、停止等操作。而 RTMP 不是一种控制协议它只负责媒体流的传输。4安全性RTMP 提供了较低的安全性因为它使用 TCP 协议进行传输容易受到中间人攻击。而 RTSP 提供了较高的安全性因为它使用 UDP 协议进行传输并支持加密和认证。5应用场景RTMP 主要用于直播和视频点播应用而 RTSP 主要用于实时视频监控和安防监控等应用。 3HLS(HTTP Live Streaming)是Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件TS媒体分片文件和key加密串文件。HLS协议一般只用作拉流观看严格来说HLS其实是一个 文本协议而并非流媒体协议它的延迟较高ts0segment-time510s。HLS只请求基本的HTTP报文与实时传输协议RTP)不同HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器它也很容易使用内容分发网络来传输媒体流。HLS一般主用于通过HTTP协议下载静态视频文件HLS协议的文件由两部分组成一是多个只有几秒长度的 .ts碎片 视频文件另一个是记录这些视频文件地址的.m3u8索引文件HLS观看地址是以http://开头、.m3u8结尾的实际上这个地址就是索引文件的地址客户端获取到索引文件后就可以下载对应的碎片视频文件并开始播放了.m3u8索引文件会记录所有的碎片视频文件地址HLS在点播的场景下优势是更加明显的。由于HLS的相关文件是无状态的静态文件且每个文件的大小是有限的所以负载均衡、CDN加速的效果更佳明显。另.m3u8索引文件支持二级索引就是高清、标清、流畅等多个观看地址可以整合到一个索引文件。播放器可以根据当前带宽自动切换不同的观看地址大部分网页播放器的“自动”也是因为这个。HLS最大的优点支持HTML5 就可以直接打开播放这意味着可以把一个直播链接进行转发分享后用户通过浏览器就能播放不需要安装任何独立的 APPHLS协议可以用于点播和直播观看可适配多种播放场景。采用HLS协议的点播视频会比.mp4、.flv的视频更快地播放出来且在加载中跳转视频也会更加顺滑。
采用HLS协议的直播场景视频流数据每几秒会打包成一个以.ts为后缀的碎片视频文件每生成一个新的视频文件都会同步更新.m3u8索引文件。且碎片视频文件的个数是有上限的当达到上限后默认会将最旧的视频文件删除且更新.m3u8索引文件。所以在直播的场景下客户端也需要不断定时重新获取.m3u8索引文件即HLS协议并不适合直播的场景。直播场景下由于需要生成静态文件直播延迟很大大概在5-30秒左右使用直播CDN的话由于边缘节点同步等问题直播延迟甚至可能会达到1分钟左右。
注由于HLS协议的视频文件、索引文件都是无状态的静态文件是直接写入磁盘的 所以如果长时间且多个直播流同时处理会造成磁盘写入压力过大机械磁盘可能会磁道会损坏固态硬盘的寿命会加速衰减。这种情况下最好挂载一段内存空间作为HLS相关文件的写入位置以减轻磁盘写入压力过大的问题。
4流stream数据在网络上按时间先后次序传输和播放的连续音/视频数据流。之所以可以按照顺序传输和播放连续是因为在类似 RTMP、FLV 协议中每一个音视频数据都被封装成了包含时间戳信息头的数据包。而当播放器拿到这些数据包解包的时候能够根据时间戳信息把这些音视频数据和之前到达的音视频数据连续起来播放。而像MP4、MKV 等这类封装必须拿到完整的音视频文件才能播放因为里面的单个音视频数据块不带有时间戳信息播放器不能将这些没有时间戳信息数据块连续起来所以就不能实时的解码播放。
WebSocket
GA/T 1400协议 数字视频录像机DVR 网络视频录像机NVR SIP协议SIPSession Initiation Protocol会话发起协议是一个用于建立更改和终止多媒体会话的应用层控制协议其中的会话可以是IP电话、多媒体分发及多媒体会议。SIP协议采用Client/Server模型主要通过与代理服务器之间的通信来完成用户呼叫的建立过程。
2.2、GB28181网络视频协议
GB28181协议是指遵循国家标准GB/T 28181—2016《公共安全视频监控联网系统信息传输、交换、控制技术要求》中所要求的进行视频处理的约定标准。它也是我国公安部提出的一个通用的视频监控联网协议。它规定了视频监控系统中前端设备、平台服务器、客户端之间的通信协议和数据格式旨在实现不同厂家、不同设备之间的互联互通。其中 1.该标准规定了公共安全视频监控联网系统的互联结构 传输、交换、控制的基本要求和安全性要求 以及控制、传输流程和协议接口等技术要求是视频监控领域的国家标准。 2.GB28181协议信令层面使用的是SIPSession Initiation Protocol协议 3.流媒体传输层面使用的是实时传输协议Real-time Transport ProtocolRTP协议 GB28181协议数据包封装格式
如上图所示视频连网系统在进行视音频传输及控制时应建立两个传输通道会话通道和媒体流通道 会话通道用于在设备之间建立会话并传输系统控制命令媒体流通道用于传输视音频数据,经过压缩编码的视音频流采用流媒体协议 RTP/RTCP传输 2.3、常见视频管理架构 三、问题及故障
3.1、视频断流
现场远程会议室录像机是通过国标GB28181协议注册到视频管理平台后视频播放了一会儿就出现了断流的现象。
处理现场抓包设备查和sip协议查看视频流推送通信过程设备端会主动发bye导致断流然后更换网络环境测试对比排除当现场配置有防火墙时对外的端口未能恰当开放会导致断流现象。
eg1相关经验表明当设备网络较差时设备会出现断流超过指定的超时时间30s(各平台默认值不同)就会主动清除流媒体服务但是redis中的流数据还在而当设备在录像时自动保活会从redis中取保活流数据所以就会出现设备状态显示正在播放但是流已经消失的情况。这时就需要检查对流的判断确保异常后可重新拉流现场实际为断流后会重试拉流。
3.2、视频串流
GB28181协议下频繁出现串流和断流的问题主要涉及到几个方面设备配置冲突、网络问题、协议实现的不一致性以及服务保活机制的问题主要出现在网络方面。
1摄像设备配置冲突 如果现场两台设备配置冲突比如配置参数SIP用户ID必须为唯一值一般会根据地区编码设置不同ID否则会向视频管理平台进行不间断地注册这样就会导致这两台设备的视频流冲突一会是A设备的流一会是B设备的流。 \ 2网络问题 在网络通信过程中随着视频流并发和资源下载等负载增高出现通过国标GB28181协议注册到视频监控平台后频繁断流可能是因为现场网络环境存在问题如防火墙设置导致端口未能开放进而影响视频流的正常传输。可通过开启对应端口后尝试查看视频流是否可恢复正常。 eg1当设备网络较差时设备会断流超过指定的时间30s(各平台默认值不同)就会主动清 除流媒体服务但是redis中的流数据还在而当设备在录像时自动保活会从redis中取保活流数据所以就会出现设备状态显示正在播放但是流已经消失的情况。 3协议实现的不一致性 GB28181协议在实施过程中由于不同厂商的实现可能存在差异导致协议解析出现问题进而影响到服务稳定性。例如部分机型不按照标准ps协议封包导致级联平台中的ssrc直接默认为0无法使用ssrc校验码流从而引发串流问题。此外rtp码流无法避免串流和异常码流攻击即使采用ssrc校验也不能完全避免。 4服务keep-alive机制的问题 在设备进行播放保活时如果对流信息判断不当可能导致断流现象。例如如果设备端主动发送bye信令而服务端未能正确处理这种情况就会导致视频流意外断开。解决这一问题的方法包括对流信息进行正确判断并在必要时自动重新拉流。 5通道占用问题 相关经验中当通过数据库查看设备状态实际离线后即它的通道实际也就离线了但页面检查会发现设备通道是在线状态故前台也会显示该设备在线然实际是该摄像头使用了其他通道的标识导致最终出现串流。故在代码层面应检测设备时如果处于离线状态只需将关联的通道也置为离线状态即可。
