smarteye+webRTC全面支持GB35114国标，WebSocket, RTMP,RTSP,FLV,TS,HTTP-FLV,H.265, WASM

国标GB35114基本上是在GB28181基础上，扩展安全加密的支持，GB35114的支持可以使得原本已有的国标平台更加安全健壮. 

VMS/smarteye支持音视频点播/直播服务器，一款高性能的流媒体服务器，支持RTMP推流，同步输出RTSP、RTMP、HLS、HTTP-FLV、WebSocket-FLV、WebSocket-RTMP，支持推流分发/拉流分发，支持秒开、GOP缓冲、录像、检索、回放、录像下载、网页管理等多种功能，是目前市面上最合理的一款商用流媒体服务器；支持视频会议服务，支持音频会议、视频会议、会议录像与回放、直播流接入等； 

对于H5视频可视化在视频播放上如何做到无插件H5展示的方法。 

除了HTTP、WebSocket类的传输协议，其他是无法通用地传输到浏览器的，所以，如果要做一款通用的H5视频播放器，基本上就是一款HTTP/WebSocket协议的视频播放器，如果是类似于RTMP、RTSP类型协议的视频源，是不可避免，需要经过服务器转换的，那么我们可以总结Web网页可视化直播的几个刚性需求：

 H5播放只支持HTTP、WebSocket协议的流媒体源；

需要同时支持H.264、H.265视频编码格式；

支持低延时的实时视频以及录像回放视频；

WebSocket透传

通过WebSocket代理服务器，建立透传通道，转发各种不同协议的视频流，WebSocket类似于一个管道，只做原样的数据转发，将源设备与H5客户端之间建立一条由WebSocket包裹的传输通道，具体的协议交互过程还是按照原协议进行，RTSP、SIP类的文本协议按照文本协议的方式，RTMP类的字节流协议按照字节流协议的方式；

前端兼容性开发难度高：前端对于各种信令协议、字节流协议、以及解包、缓冲区、时间戳同步、解码、显示、播放，都要开发，对于前端开发的要求比较高；

H.265播放技术：安防场景下，大部分摄像机都采用的是H.265编码格式，所以，要前端Web支持H.265格式，需要引入wasm技术；

方案优缺点：

后端只做管道，不具备实际的设备信息知悉权，这对于设备的管控是无法做到的，例如，无法快照、无法录像、无法获取设备具体的错误信息；

协议转换

采用全协议接入方案，将各种不同协议类型的视频源（RTSP、RTMP推流/拉流、HTTP、UDP等）、视频文件，通过标准化的协议转换，统一可以输出为HTTP-FLV（实时流）、HLS（直播流/点播流）对终端进行输出，就达到了标准化、全终端、全平台输出了；

后端兼容：后端需要将各种协议接入，并进行解封装，封装成标准的flv、ts等格式，不过好在已经有比较多的积累；

H.265播放器：同样是需要做到H.265的Web播放，包括HTTP-FLV和HLS的H.265格式；

可控性强，前后端分离，前后端人员均可灵活定制；

H.265网页播放方案

大家可以看到以上的两种解决方案都会具有一个H.265网页播放的难点，这里的主要原因是目前的浏览器基本都不能支持H.265的底层解码，或者说硬解码，H.265需要结合原生播放器的开发技术和Web播放器的开发技术，也就是wasm技术，将C/C++封装成wasm，被js调用，这样js就能像C/C++原生播放器一样，充分利用C/C++的计算能力和扩展能力，来实现视频的解码过程。