视跃realgbs基于GB28181协议开发的，支持海康，大华，宇视等摄像机接入，通过GB28181协议统一进行管理的视音频综合平台。他支持web，andorid，pc端三种形态对接入的设备进行管理。
作为轻量级的使用方式，很多用户会用web直接进行视音频的调阅与预览，所以web无插件的预览是十分重要的功能，但是web无插件的视频延时往往会逊色于使用客户端进行接入设备视频的预览。
网上几乎所有的厂商都采用的rtmp转发，采用的一般是第三方的工具，比如nginx，srs等，他可以把rtmp转发为http flv，rtmp，hls等视频流媒体，这是一种直播的使用方式，实现起来比较简单，我们也曾考虑这样实现，其优缺点如下：
缺点：
1.延迟较大，GB28181的ps流转rtmp后推nginx（或者srs）转发成rtmp/http flv/hls造成延时较大。
2.调用第三方工具进行媒体转换和转发，造成对整个系统流媒体的控制性不好，推上去后，就推上去了，可能web用户已经没人预览了，但是后台还在往nginx或者srs上推流，我们也会去定时去轮巡web端的http会话，发现没有web用户预览的设备，就发bye，停止拉流（可能就是一些厂家定义的“按需直播”），但是总觉得这样可控性差，不能与前端会话实时互动，造成了带宽浪费，而且还需要造成额外的性能消耗。
优点:
1.如果设备一直在无差别推流，用户想预览这路流，那么往往首屏时间会快点，理论上省去了拉的过程，因为流一直推在nginx或者srs上，随时等待用户来预览。
其实优点和缺点说白了就是一句话，适合网络直播，适合很多粉丝去预览同一个设备的音视频流这样的场景，网络直播的用户级别也不会存在这个直播没有用户去看了，主播还在播的情况（无差别推流）。直播对延迟是不敏感的，在斗鱼的同事说他们直播延迟10s都很正常，为了达到首屏显示的速度，往往还会缓存1-2个GOP，去保证用户预览立即显示。
但是做过军工行业的我，对延时太敏感，而我们不仅仅做平台，还做GB28181前端设备sdk（无线4G/5G）,移动设备对流量是苛刻的，所以决定不用第三方推流工具，自己去实现流媒体协商，这样全程自主可控，自己实现转发，这样大大的降低了延时，同时前端web用户停止预览后，因为整个会话自己实现可控，所以实时给设备发bye，销毁会话。这样完美实现了低延时的web无插件直播，整个过程用户发起，用户关闭，没有多余的拉流和冗余的会话存在。
最后在外网环境下（很普通的外网），平台通过GB28181接入海康的摄像机，用web无插件预览进行测试延时，延时在700多ms，这不是理想的状态（非专网，而且用的tcp被动），理想状态延时会更低。但我们还是把常规状态的情况反映并截图如下：
我们可以看到在普通的外网下，延时是17min:34s:275ms - 17min:33s:499ms = 776ms
通过对平台的优化和改造，我们自主实现，我们的GB28181平台完成了低延时的web无插件预览。
更多信息
e-mail: [email protected]
tel: 13971177602
web：www.founu.com