GPS软件平台开发技术博客 » jt1078 http://www.jt808.com 帮助IT团队快速构建符合部标的GPS和视频平台(2379423771@qq.com) Sun, 03 Nov 2024 04:30:16 +0000 zh-CN hourly 1 http://wordpress.org/?v=3.4.1 JTT1078协议双向语音对讲和广播开发指南 http://www.jt808.com/?p=1956 http://www.jt808.com/?p=1956#comments Sun, 06 Oct 2024 08:31:15 +0000 admin http://www.jt808.com/?p=1956 部标JTT1078标准支持双向语音对讲和广播的功能，终端设备可以通过麦克风接收语音信息，并通过扬声器播放语音信息。这一功能使得驾驶员和监控平台之间可以实时进行语音沟通。

语音对讲是平台和设备终端之间的一对一的语音对讲。

广播是平向多个设备终端之间的单向语音传输；

无论是语音对讲或者是广播，都只能是平台用户发起请求，驾驶员司机不能通过设备终端主动发起请求。但是驾驶员可以通过终端发起紧急报警，监控人员收到紧急报警后可以调取视频画面，并发起语音对讲。

语音对讲在苏标主动安全平台中的应用场景。

苏标主动安全平台，虽然是基于短视频报警触发的主动安全管控机制，但它也需要实时监控和语音对讲功能的辅助，常规的功能是当前端收到主动安全报警辅助的时候，可以立即打开视频监控和语音对讲，对违规司机进行口头劝诫。如下图所示。

这也就是我们常说的报警联动功能的应用之一。

基于部标1078视频协议和苏标Adas协议构建主动安全平台

苏标主动安全报警

 

语音对讲面临的一些问题：

1) 语音对讲的通道是虚拟通道，不像摄像头所占用的通道是物理通道，原则上这个对讲的通道号是个什么数字都是无所谓的，但是很奇怪的是，很多厂家开发的时候，强制设定对讲的通道号只能是1，不是1，对讲就不可能成功。正常由于对讲是平台发起的，平台下发请求的对讲通道号是什么数字，那么终端按照这个数字来回复和打包RTP数据包就可以了；

2) 对讲和实时视频理论上不应该互相影响，但有些设备不支持一边看视频，一边对讲。这就造成了无法满足视频通话的需求；

3)   JT078的RTP包头并没有标记区分是实时视频，历史回放视频，和语音对讲数据包，这就造成了在同一个端口，同一个通道是无法同时传输这三个数据包，服务器必须要采用不同的端口来接收并区分这三个数据包；

广播这一块漏洞比较大，可能设计者觉得没有什么应用场景，就设计一个指令草草了事，实际上广播这块目前存在的问题如下：

1) 平台主动发起广播，很多厂家设备设计的时候，收到广播请求后，只是向服务器建立了一个空的数据连接，但是不发一个数据包，这样平台就不可能知道这个连接来自那个车辆设备的，就像开远程会议的时候，都不说话，也不知道谁连上了谁没有连接上，主讲者只顾自己开大会讲话；

2) 接入广播的设备如果来自不同的厂家，如果他们的设备只能接受不同音频的编码，如锐明只支持Adpcma, 有为支持G711, 海康支持G726, 那么下发给三家设备的广播语音，必须要三次编解码，这就是语音对讲不统一音频编码带来的麻烦；

综上，广播功能就是个摆设，没啥意义。

 

开发语音对讲和广播功能是开发部标1078视频监控平台非常繁琐的一个技术环节。开发者需要掌握一定的网络通信技术和音视频编码的技术。

主要的交互分为

1）指令交互，主要是在808网关构建的指令通道中完成交互；

2）双向音频流交互传输；

开发者主要解决的技术问题：

1）如何调用桌面麦克风获取用户录音的音频流；

2）获取设备段上传的音频流并推流到网页端播放；

3）如何编解码和传输;

 

  由于音频数据需要经历获取原始音频数据->编码压缩->传输->接收后解码还原的过程，所以开发者不仅仅需要了解基本的音视频编码基础知识和原理，还需要会进行音频编码和解码。

基本的音频编码知识

由于1078协议并没有对语音对讲的编码进行统一，实际上完全可以统一为AAC（Advanced Audio Coding），但是很遗憾就是没有，所以设备终端的语音压缩编码就是百花齐放，各自根据自己的设备芯片方案来决定编码，主要采用的编码如下：

1）G711A

2）G711U

3）G726, 最复杂，G.726 支持不同的比特率（如 16k、24k、32k、40k），需要判断终端采用什么比特率的编码；

4）Adpcma

5）AAC，最方便，对网站最有好的编码；

 

主要的参与脚色是平台1078视频服务器（中转分发), 网页前端（发起请求），终端（响应请求）

1）平台当中最核心的当然是JT1078视频服务器，视频服务器主要的职责是中转分发，音视频编码解码，连接管理，数据统计。 如需购买视频监控平台和主动安全平台源码，请联系2379423771@qq.com, 无意购买者勿扰。

部标1078视频播放器

 

2） 在网页前端需要开发者从抓取麦克风录音数据获得原生的音频数据开始，然后就是压缩，再通过websocket传输。需要开发一个复杂的播放器来完成此项工作，如下图所示：

Html5 部标视频播放器

基于spring4+springMVC4+mybatis3+Hibernate4+junit4框架构建高性能企业级的部标1078视频监控平台

前端简单DEMO代码示例如下(主要是为了说明技术流程，实际代码要远比这个复杂）：

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>麦克风录音并压缩传输</title>
  <script src="https://cdn.jsdelivr.net/npm/@ffmpeg-installer/ffmpeg"></script>
</head>
<body>
  <script>
    let audioContext;
    let mediaStream;
    let sourceNode;
    let scriptNode;
    const socket = new WebSocket('ws://your-server-url');

    async function startRecording() {
      audioContext = new AudioContext();
      mediaStream = await navigator.mediaDevices.getUserMedia({ audio: true });
      sourceNode = audioContext.createMediaStreamSource(mediaStream);
      scriptNode = audioContext.createScriptProcessor(4096, 1, 1);

      sourceNode.connect(scriptNode);
      scriptNode.connect(audioContext.destination);

      scriptNode.onaudioprocess = async (event) => {
        const pcmData = event.inputBuffer.getChannelData(0);
        const aacData = await compressPcmToAac(pcmData);
        socket.send(aacData);
      };
    }

    async function compressPcmToAac(pcmData) {
      const ffmpeg = FFmpeg.createFFmpeg({ log: true });
      await ffmpeg.load();

      ffmpeg.FS('writeFile', 'input.pcm', new Uint8Array(pcmData));
      await ffmpeg.run('-i', 'input.pcm', '-c:a', 'aac', 'output.aac');
      const aacData = ffmpeg.FS('readFile', 'output.aac');

      return aacData;
    }

    socket.addEventListener('open', (event) => {
      console.log('WebSocket连接已打开:', event);
      startRecording();
    });

    socket.addEventListener('message', (event) => {
      console.log('收到服务器消息:', event.data);
    });
  </script>
</body>
</html>

(5330)

]]> http://www.jt808.com/?feed=rss2&p=1956 0 部标jt809协议视频对接播放下级平台JT1078视频 http://www.jt808.com/?p=1937 http://www.jt808.com/?p=1937#comments Fri, 01 Jan 2021 00:00:00 +0000 admin http://www.jt808.com/?p=1937

  

部标809协议是部标协议中最复杂的协议，而其中的视频协议对接部分，又是809协议指令中最复杂的指令，也是技术实现最困难的部分。这个复杂有本身涉及上级，下级，和设备多环节交互的复杂，也有协议设计缺陷造成的复杂。 

809协议的视频指令也是一个闭环的交互流程，上级-》下级-》设备-》下级-》上级，完成指令的一个闭环操作。只不过指令应答环节有缺陷，当同时开一个车的多路视频请求的时候，多个指令并发下发给下级，造成下级应答给上级后，上级无从判断应答指令对应与开始的那路视频请求，只能强行的去尝试播放。这就给我们协议设计者一个警示，设计协议的时候，下发指令和应答一定要对应上，否则就给开发造成了逻辑上的混乱，虽然勉强能做，但是很麻烦。  

809协议指令在JT/T 1078协议文档中的第六章开始部分，分为下发指令和视频播放两个部分，两个请求环节，也就是说要先完成视频指令下发给设备的闭环操作，然后再开始请求视频播放的请求操作。这两个环节完成了上级平台播放下级企业平台的设备视频的流程。 

下级平台必须要实现1078协议中的809指令部分，必须要按照809协议的要求，提供接口，上级平台才能完成播放。所以双方对接的时候，首先要确认对方是否实现了809视频指令及接口。 

下级平台提供给上级平台的接口，按照规定下级平台要扮演Http Server的角色，提供Http API供上级平台调用指定的API，上级平台调用Http API接口获取到视频流，进行转发或者直接播放。所谓的HttpAPI接口，其实就是一个URL，上级平台要扮演一个Http Client的角色去调用这个URL，在Response中获取到视频数据进行播放处理。 

政府视频监管平台向企业视频监控平台发送实时预览或远程回放请求指令并得到成功应答后，获取到音视频流服务器的IP地址和端口号，由政府视频监管平台客户端直接向企业音视频流服务器发送URL指令，建立链接后获取音视频流数据，客户端通过浏览器插件或专用软件进行播放。

音视频流请求URL不应在界面中显示，指令格式具体定义如下：

http://［服务器IP地址］：［端口号］／［车牌号码］．［车牌颜色］．［逻辑通道号］．［音视频标志］．［时效口令］

 

虽然是基于Http的协议，但是一般的H5播放器是不能直接播放的，需要获取到数据后重新编码然后再喂给H5播放器才能直接播放。所以这个也是协议设计的一个缺陷，正常的视频协议设计的时候，对于视频的格式应该进行明确的定义，采用主流的格式，如flv或者fmp4格式，这样通用播放器就可以直接播放了。目前需要自己定制播放器进行开发。 

另外一种方式是由后台获取下级平台的视频数据，然后重新解码编码，封装成web播放器锁支持的格式进行播放，这种方式也是可行的。 

希望未来的协议设计的时候，能够有更多丰富经验的设计者参与进去，而不是降维设计，让大家都很痛苦。 

如果需要购买809平台，可以联系2379423771@qq.com

 java版的参见:基于Java Mina 通信框架的JT/T809转发服务器设计

如果用809协议接收第三方平台转发的数据，并开发web系统进行数据展现、报警提示、地图监控、电子围栏等功能，参见文章（C#和Java都有)：基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台

C#版的交通部809服务器设计请参考：基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器

 部标809播放JT1078协议视频

 

 

 部标809-2019上级平台政府运管服务器

 

 

 

 

 

 

(6621)

]]> http://www.jt808.com/?feed=rss2&p=1937 0 沪标主动安全平台系统架构和功能列表 http://www.jt808.com/?p=1921 http://www.jt808.com/?p=1921#comments Thu, 26 May 2022 10:56:22 +0000 admin http://www.jt808.com/?p=1921

上海市交通运输行业协会在2019年发布的主动安全平台标准, 简称沪标, 沪标也是以苏标主动安全标准为基础做了进一步的改造,  但改动地方相对多一些, 特别是有重点的对驾驶员监管方面, 比如人脸识别, 超载等方面做了加强. 主要包含以下四个标准规范,

1) T/SHJX 012—2019《道路运输车辆主动安全智能防控系统 （平台技术规范）》

2) T/SHJX 013—2019《道路运输车辆主动安全智能防控系统 （平台通讯协议规范）》

3) T/SHJX 014—2019《道路运输车辆主动安全智能防控系统 （终端技术规范）》

4) T/SHJX 015—2019《道路运输车辆主动安全智能防控系统 （终端通讯协议规范）》

主要规范了道路运输车辆主动安全智能防控系统架构，以及道路运输车辆主动安全智能防控系统中上海市重点营运车辆联网联控系统和道路运输企业监控平台的功能要求、性能要求与技术要求等内容，以指导道路运输车辆主动安全智能防控系统上海市重点营运车辆联网联控系统和道路运输企业监控平台的建设，特制定本标准。

参与制定的会员企业

本标准主要起草单位：上海英迪信息技术有限公司上海中安电子信息科技有限公司上海赛格车圣导航科技有限公司上海英杰特信息技术有限公司上海卫脉信息技术有限公司. 这些公司基本都是第一批就过了沪标检测.

规范要求平台需要支持以下几种部标标准协议要求:

1) GB/T 35658智能运输车辆卫星定位系统平台技术要求

2) JT/T 808 道路运输车辆卫星定位系统终端通讯协议及数据格式

3) JTT 809 道路运输车辆卫星定位系统–平台数据交换

4) JT/T 1077 道路运输车辆卫星定位系统车载视频平台技术要求

5) JT/T 1078 道路运输车辆卫星定位系统车载视频通信协议

道路运输车辆主动安全智能防控系统的架构设计

道路运输车辆主动安全智能防控系统包含卫星定位子系统、视频子系统、主动安全报警子系统，其中卫星定位子系统和视频子系统应符合JT/T808、JT/T809、GB/T35658、JT/T1077及JT/T1078等标准中的要求。

主动安全报警子系统包含上海市重点营运车辆联网联控系统、道路运输企业监控平台、主动安全智能防控终端以及主动安全智能防控平台与主动安全智能防控终端间的通讯网络。通过各组成之间的互联互通，实现卫星定位、视频监控、主动安全智能防控管理以及数据存储、分析、交换和共享。主动安全智能防控平台与用于位置监控和视频监控的平台在实际应用中可以是同一软件系统的不同功能模块。

上海市重点营运车辆联网联控系统与道路运输企业监控平台之间通过原联网联控通信链路进行连接，主动安全智能防控终端与道路运输企业监控平台之间通过无线通信网络单链路连接，实现对车载主动安全智能防控终端所采集的报警数据进行查询、统计、分析以及管理等功能。道路运输车辆主动安全智能防控系统主动安全报警子系统架构如图1所示

 沪标主动安全

平台需要通过沪标检测认证,

目前检测单位主要是:交通部信息中心指定的几家检测机构,如交通运输通信信息工程质量检测中心,石家庄54所等机构检测认证. 

本平台已经通过沪标的检测, 如需购买源码, 可以联系2379423771@qq.com

粤标主动安全平台主界面

5上海市重点营运车辆联网联控系统

5.1基础功能

上海市重点营运车辆联网联控系统基本功能应满足GB/T35658和JT/T 1077相关功能。

5.2扩展功能

5.2.1用户管理

用户管理应满足JT/T 1077中第5章5.2用户管理中描述的功能。

5.2.2.报警类型

上海市重点营运车辆联网联控系统可接收接入平台上报的报警主要包含车辆前向碰撞报警、车道偏离报警、车距过近报警、疲劳驾驶报警、分神驾驶报警、抽烟报警、接打电话报警、驾驶员异常报警、DSM摄像头被遮报警等。

5.2.3.报警管理

上海市重点营运车辆联网联控系统应具备接收接入平台上报的车辆报警信息及对应的报警处理信息的功能。

5.2.4.报警信息分析

5.2.4.1报警展示

报警展示功能可具备根据不同分类对接入平台上报的报警信息进行处理功能，支持按照报警类型、车辆类型、企业对报警信息进行分类汇总、展示分析，并支持将汇总结果、分析结果以直观统计图表展现。

5.2.4.2驾驶员分析

上海市重点营运车辆联网联控系统可具备通过报警数据分析对驾驶员的驾驶行为进行统计分析的功能，能够按照不同报警类型、报警数量、报警等级等相关信息，按照管理规定生成驾驶员驾驶行为统计报表，也可具备用户按照驾驶员信息字段进行查询的功能。

5.2.5企业运营分析

5.2.5.1企业车辆数据分析

上海市重点营运车辆联网联控系统应能够实现对所有入网企业的车辆数据进行分析，按照需求生成不同类型的分析报表，支持显示企业当前车辆入网数量、在线数量、入网率、在线率等相关信息，能够以图表等直观形式显示企业一段时间内在线率等相关信息的变化规律。

5.2.5.2企业报警处理情况分析

企业报警处理情况分析主要包含对所有入网企业报警信息处理、处理情况的分析，应能按照用户需求生成不同类型的分析报表。支持显示企业所有报警信息的处理响应时间和结果等相关信息，并支持按照分析选定时间段、报警等级、车辆类型分类方式分析企业报警处理响应时间、处理率等指标。

5.2.5.3企业运营管理统计分析

上海市重点营运车辆联网联控系统可具备对所有入网企业运营管理情况进行统计的功能，支持按照车辆入网率、在线率、报警处理响应时间、处理率等相关指标综合评价企业一定时间内的运营管理情况，并生成企业运营管理统计分析结果。统计分析规则应根据管理部门相关管理办法进行。

5.2.6.信息管理与发布

上海市重点营运车辆联网联控系统应当能够向接入平台发布相关信息、政策。

6道路运输企业监控平台功能

6.1基础功能

企业安全监管平台基本功能应满足GB/T35658和JT/T 1077相关功能。

6.2扩展功能

用户管理用户管理应满足JT/T 1077中第5章5.2用户管理中描述的功能。

6.2.2.报警类型

道路运输企业监控平台应支持接收由主动安全智能防控终端触发前向碰撞报警、车道偏离报警、车距过近报警、疲劳驾驶报警、分神驾驶报警、接打电话报警、抽烟报警、驾驶员异常报警、DSM摄像头被遮报警等。报警信息实时监控及处理道路运输企业监控平台应实现对车辆主动安全报警信息的实时处理，终端根据车速与报警参数将报警分为一级报警和二级报警，具体分级策略参见终端技术规范，平台接收到报警时应可分析并对报警级别进行分析处理，具体措施如下：

a) 平台接收到报警时，应当记录报警信息并存档；

b) 如车辆在单位时间内上报报警达到一定数量，平台应产生一条驾驶员主动安全的高级别报警

c) 平台接收到高级别报警时，应记录报警信息并存档，同时应以声音或图像的方式提醒监控人员。

d) 平台应支持监控人员对主动安全报警进行实时处理，记录报警处理结果信息并存档。道路运输企业监控平台应能够存储平台内车辆的主动安全智能防控相关信息，报警信息包含报警类型，报警等级，报警开始时间，报警结束时间，报警时车速，经纬度，高程。

6.2.4.报警远程调视频（危险品）

当危险品车辆发生超速、出入禁行区域报警、JT/T 808规定的疲劳驾驶报警，平台应通过远程调阅视频方式或终端主动将报警发生前后5秒（时间可设定）视频保存平台。

6.2.5.报警远程调视频（客车）

当客车车辆发生2-5点报警、超速、JT/T 808规定的疲劳驾驶报警，平台应通过远程调阅视频方式或终端主动将报警发生前后5秒（时间可设定）视频保存平台。

6.2.6.报警查询

道路运输企业监控平台应能够实现对所有相关企业车辆报警信息的查询，按照需求生成不同类型的查询报表，具体要求如下：

a) 支持按驾驶员查询报警信息。

b) 支持按车辆牌照查询报警信息。

c) 支持按照报警类型、报警等级查询报警信息。

d) 支持按时间段查询报警信息。

e) 支持对所查询报警信息相关音视频、照片证据的回放。

f) 支持查询信息报表生成功能，生成包含查询时间段、查询发起方身份、详细报警信息等在内的查询报表，并应支持报表的导出功能。

6.2.7.报警信息统计与分析

道路运输企业监控平台应能够实现对所有相关企业车辆报警信息的分析，按照需求生产不同类型的分析，具体要求如下：

a) 支持对企业报警类型进行统计分析，可直观展现各种类型报警的相对比例。

b) 支持对企业内驾驶员关联报警进行分析，可形成驾驶员驾驶行为统计报表。

c) 支持对企业内车辆关联报警进行分析，可形成车辆报警统计分析图。

6.2.8超员检测（客车）

车辆运营过程中，企业平台具备接受车载终端定时抓拍的车厢照片，并通过图像算法分析客车是否超员，并提供相关的报表查询功能。

6.2.9.驾驶员档案管理

道路运输企业监控平台应当设立驾驶员档案库。支持将驾驶员信息录入驾驶员档案库的功能。驾驶员档案库信息应包含驾驶员个人信息、驾照信息等相关信息，同时支持建立包含正面照在内的驾驶员人脸库。

6.2.10.司机身份识别

企业平台应能够接收来自终端设备定时抓拍司机正脸图片，通过人脸识别算法，以及平台存储的司机人脸库信息，识别出司机身份。

6.2.11.非法司机报警

企业平台应能够通过人脸识别技术，鉴别司机是否合法合规，一旦判定司机不合法合规，即时报警。

6.2.12.驾驶员分析

道路运输企业监控平台应支持根据驾驶员相关驾驶行为数据对驾驶员驾驶行为进行综合分析的功能，平台应能够按照相应指标对驾驶员驾驶行为进行周期性统计，平台用户可按照不同标准对驾驶员驾驶行为进行统计分析。

6.2.13.车辆终端信息管理

道路运输企业监控平台应当支持对主动安全智能防控终端安装信息的管理。所有入网车辆所安装的主动安全智能防控终端品牌及型号应当在道路运输企业监控平台中详细记录。平台应支持按照车牌号、所安装主动安全智能防控终端的品牌型号等条件查询相关车辆信息，且支持对于车辆安装信息的更新、修改及删除。

6.2.14.接收信息与展示

道路运输企业监控平台应具备接收政府监管平台下发的信息，并能够提示企业管理人员。

6.2.15.终端在线升级

道路运输企业监控平台应支持对车载终端的在线升级推送功能，当有车载终端软件升级包时，平台向终端发起在线升级指令，终端根据平台提供的升级包下载地址获取升级包进行自动升级，并在升级成功后向平台发送升级成功指令，平台同时记录升级后的终端软件版本信息。平台支持在线升级策略管理，包含单位批次数量、定时升级任务以及选定设备手动升级等功能。

6.2.16.移动终端支持

企业平台应提供移动终端接入展示功能，至少提供实时位置和轨迹回放、视频点播和回放、报警展示，移动端产品形式可以为手机APP或微信公众号等方式。

7主动安全智能防控平台性能与技术指标

7.1主动安全智能防控平台总体性能

主动安全智能防控平台总体性能应至少满足以下要求：

a) 支持平台7×24h不间断运行；

b) 在没有外部因素影响的情况下，故障恢复时间不超过120min；

7.2应急与报警信息响应时间

报警及报警信息处理至少满足以下要求：

a) 应急与报警信息响应时间不超过10min；

b) 优先保证报警信息及报警处理信息显示。

7.3主动安全智能防控平台

车辆接入性能主动安全智能防控平台车辆接入系统应满足以下要求：

a) 具有主动安全报警数据高并发处理能力：平均1000条/s、峰值3000条/s。

b) 道路运输企业监控平台能支持至少10，000台主动安全智能防控终端接入。

c) 上海市重点营运车辆联网联控系统能支持至少100，000台主动安全智能防控终端接入。

7.4主动安全智能防控平台响应时间

最大并发用户数达到其系统设计要求时，各事务平均响应时间不应超过单用户平均响应时间的五倍。

7.5网络传输网络传输环境应满足以下要求：

a) 上海市重点营运车辆联网联控系统之间支持专线网络或互联网VPN连接；

b) 道路运输企业监控平台支持互联网或专线网络等方式连接上海市重点营运车辆联网联控系统。

7.6报警数据存储

主动安全智能防控相关数据存储及备份要求如下：

a) 报警信息数据存储时间不得少于183天；

b) 报警多媒体附件数据存储时间不得小于90天；

c) 上海市重点营运车辆联网联控系统离线保存的报警多媒体数据存储时间不得小于365天。

d) 建立报警信息数据备份机制，每周对数据进行增量备份，每月对报警信息数据进行全量备份，备份报警数据时间不得小于1年，系统数据恢复时间不超过12h。

7.7安全要求平台部署环境

安全应满足以下要求：

a) 满足GB 17859第3级及以上安全要求；

b) 数据库中关键数据加密存储，用户密码加密存储；

c) 采用日志对操作和接受及发送的数据记录，至少存储183天日志数据；

d) 采用备份平台，主平台出现问题能自动切换到备份平台；

e) 平台间数据交换采用加密传输方式，具体要求应符合道路运输车辆卫星定位系统平台数据交换的相关规定。

7.8主动安全智能防控平台运行环境运行环境应满足以下要求：

a) 通信网关、应用服务器和数据库服务器独立部署；

b) 数据库服务器能支持大数据量存储于检索；c)局域网网络数据交换速度应不低于1Gbps。

 

(5253)

]]> http://www.jt808.com/?feed=rss2&p=1921 0 GB28181协议和JT1078视频服务器的区别和集成 http://www.jt808.com/?p=1833 http://www.jt808.com/?p=1833#comments Sun, 20 Dec 2020 07:56:01 +0000 admin http://www.jt808.com/?p=1833 GB28181的全称是指《公共安全视频监控联网系统信息传输、交换、控制技术要求》, JT1078主要是指交通部的车载视频监控协议, 两者适用于不同的领域, GB28181规定了城市监控报警联网系统中信息传输、交换、控制的互联结构、通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、传输流程和协议接口等技术要求.主要是适用于公共场所的视频监控, 设计之初是适用于有线局域网环境, 2011发布的版本主要是UDP协议, 后来针对互联网的需求,进行了增补TCP的需求. 

1.过检认证需求:

两者都需要到主管部门指定的检测机构检测, GB28181是需要通过公安部一所、公安部三所的认证,

JT1078是需要通过交通部信息中心指定的几家检测机构,如交通运输通信信息工程质量检测中心,石家庄54所等机构检测认证. 

2.主要版本:

GB28181有2011版本, 和2016版本,

JT1078目前只有2017年发布的版本. 最近几年, 地方上开始有了2019版本的变体, 但是官方还没有正式的2019版本.

3.基于协议:

GB28181主要是以UDP为主, 多数设备以有线接入,面向局域网环境 少数手持执法设备以4G接入;

JT1078主要是以TCP为主, 由于车载设备多以无线4G接入. 

GB28181的指令协议是SIP协议,文本协议, 扩展性较强, 但是占用流量较大, 在内网无所谓, 在外网, 如果用于几千辆车带车队目录的同步, 每个车有四路摄像头, 这个流量还是比较大.

JT1078的指令协议是部标808协议, 二进制格式, 惜字如金, 适用于无线对流量费比较敏感的环境.

4.视频流格式:

GB28181的视频流比较复杂, 主要是RTP + PS + H.264的封装.

部标1078视频流的封装相对比较简单, 主要是RTP +H.264, 少了PS层. 

5.架构设计

两者在协议结构上都是类似的, 都是分为指令和数据两部分, 各自独立的两个通道, 一个长连接保持用于指令的交互, 一个数据连接用于流媒体上传, 生命周期随着用户指令结束播放而结束.

所以在架构设计上也是一样的, 需要两个子系统 : 一个网关, 一个流媒体服务器, 各司其职.

6.GB28181相对于JT1078的优势:

1. 有非常成熟的级联方案,上下级之间,同级之间都可以层层级联, 可以推送下级平台的组织架构目录树和设备及状态.

2. JT1078没有比较好的级联方案, 各级视频平台无法层层级联, 上级平台主要依托于JT/T 809协议 进行视频请求. 

由于GB28181的非常好的级联设计, 我们可以很方便的将部标企业平台的车辆树通过GB28181的SIP协议指令给同步过去, 对方的GB28181平台接收到同步数据后,自然就形成了一个组织架构树, 叶子节点为摄像头.

但由于要考虑级联,所以GB28181的视频请求流程相对于JT1078的指令来说 是根据复杂的, 详细的GB28181视频请求流程图如下:

GB28181视频请求流程

两者本来没有什么交集, 今年来, 有些地方标准如川标,要求将车载视频转入到公安部的GB28181平台进行监控, 两者慢慢发生了交集.两者以两种方式发生交集:

1. 一种是车载视频设备通过部标1078视频协议接入部标企业平台, 然后通过音视频转换和转发 转入GB28181平台.

2. 一种是固定场所的28181设备和车载设备一样,混合接入到部标企业平台当中.

 

两种方式都需要设计中间件,进行复杂的协议转换,音频编解码,以及数据转发, 在编解码及转发过程中, 要保持高性能的交换,避免产生视频延迟.

JT808.com在已有的视频服务器的基础之上, 增加了GB28181的协议转换, 使得视频服务器可以将1078视频流,转换为GB28181的PS流, 推流到GB28181视频监控平台.

主要的功能如下:

1) 平台间注册和鉴权

2) 自动定时推送设备列表和目录列表, 对车载设备和所属组织架构进行GB28181行业规范编码, 定时推送到GB28181监控平台, 监控平台自动形成监控层级目录, 并实时同步设备的上线下线状态.

3) 音频视频PS推流

如需购买视频平台源码, 请联系2379423771@qq.com

GB28181协议和JT1078协议

 

(9504)

]]> http://www.jt808.com/?feed=rss2&p=1833 0 出租车jt/t 905协议与部标1078协议融合的网约车视频监控平台 http://www.jt808.com/?p=1632 http://www.jt808.com/?p=1632#comments Sat, 18 May 2019 10:02:31 +0000 admin http://www.jt808.com/?p=1632

出租车jt/t 905协议，是jt/t 808协议的一个变种，设计者将部标808协议拿过来，并不是单纯的增加网约车相关的指令集，而且对原有的指令如定位0×0200指令也进行了修改，经过一通剧烈的修改，面目全非，协议已经与808协议本身并不兼容，这是比较失败的地方，保持兼容性，才能使协议更加让硬件和网约车平台接受和开发推广，没有经验的协议设计者和标准制定者高高在上不考虑兼容性，给硬件厂家和平台开发人员造成很大的麻烦，也增加了成本。 

部标1078协议是在部标808协议的基础上，继续增加指令，并不修改原有的指令，这样也使得协议更加容易让人接受和推广。 

在部标1078视频协议推出后，905终端就相对比较尴尬，以前的905协议本身没有视频指令和功能，很多厂家就集成基于私有协议的视频模块，五花八门，现在部标视频标准一出，就面临一个视频标准统一的问题，原有的私有协议需要抛弃掉，修改成1078协议。但是1078协议是基于808协议的指令集，并不是基于905协议的指令集，本质上不是为905协议终端设备设计的。这就需要硬件和平台后端都需要做一定的工作，才能让一个905网约车平台具备1078视频功能。 

一种比较理想的方案是深度集成，将1078协议中的指令集添加到905的指令集中，这样使得905协协议赋予了视频指令交互的能力，这种方案好的地方在于它仍然保持了一个指令通道，一个视频数据通道，但是需要硬件开发人员一定的工作量。 

另一种方案就是粗暴简单，905模块和1078模块，分别与平台后端建立独立的指令交互的连接，905的连接只交互905的指令，1078的连接只交互1078的指令，各自为战，这种方案的优势在于硬件拿来即用，不需要过多的开发，但是后遗症很多，苦了平台开发人员，设计两个指令网关，一个是905指令网关，一个是1078指令网关，在平台上下发指令的时候，需要判断指令类型，来决定指令的走向，是下给905网关，还是下给1078网关。

还有一个麻烦的地方，就是上线和离线不同步，比如1078连接断开了，而905的连接还是正常，这就在前端界面的上线状态上给用户容易造成困惑，有时候905明明在线，但是视频指令却下发失败，无法看到视频。 

在上级平台对接方面，也是麻烦，首先要基于905协议第四部分中数据交互与共享单元中的数据交换协议（是809协议的变种，做了修改，不兼容809），开发转发服务器，将数据转发给出租车监管平台。

但是还要基于原有的809协议，开发转发服务器，将数据转发给省级监管平台。 

这样开放下来，一个网约车后端，就有N多的服务器模块了，主要有：

1）905协议网关；

2）1078协议网关；

3）基于905协议数据交换部分的上级平台转发服务器；

4）基于809协议的转发服务器；

5）基于905 UDP升级协议的的升级服务器；

jt/t 905协议的网约车平台 

 

 

 

 

 

 

 

 

(10511)

]]> http://www.jt808.com/?feed=rss2&p=1632 0 基于JT/T 1078协议设计和开发部标视频服务器 http://www.jt808.com/?p=1584 http://www.jt808.com/?p=1584#comments Sun, 07 Apr 2019 09:21:47 +0000 admin http://www.jt808.com/?p=1584   交通部与2016年10月份推出了JT/T 1078-2016标准，全称是<道路运输车辆卫星定位系统视频通信协议>。该标准将改变以往两客一危车辆的视频监控设备通信协议都是设备厂商私有协议的局面。标准起草单位：交通通信信息中心、北京国交信通科技发展有限公司、江苏威森通讯科技有限公司、大连信开数码软件有限公司、深圳市锐明视讯技术有限公司、广州亿程交通信息有限公司、深圳市瑞信视讯技术有限公司、吉林省寰旗卫星导航通信集团有限公司、杭州海康威视数字技术股份有限公司、大连鼎视科技有限公司。这里面真正做视频老牌厂商也就是海康、大华这两家公司。 

1.部标1078协议和808协议的区别

  部标1078协议文档明确说明了，协议是在JT/T 808协议的基础上进行增加了大量的视频指令，以前的终端32位报警，由于增加了视频报警，拓展为64位报警。终端参数中也增加了大量与视频相关的参数设置。协议的通信方式、数据类型、传输规则和消息组成按照 JT/T 808-2011中第 ４ 章的要求。协议中信令数据报文的通信连接方式按照 JT/T 808-2011中第 ５ 章的要求。协议中信令数据报文的消息处理机制按照 JT/T 808-2011中第 ６ 章的要求。协议中信令数据报文的加密机制按照 JT/T 808-2011中第 ７ 章的要求。

  可见1078协议仍然是基于部标808协议继续拓展的协议指令集，不过在1078协议中分为信令和数据两个独立的通道，也就是视频设备与视频平台的服务器之间是建立两个通道：

  1）信令数据通道：数据格式应符合 JT/T 808-2011的规定，并在其协议格式的基础上添加新的协议指令及数据格式。 报文通信应使用车载视频终端和企业视频监控平台之间已建立的、用于传输定位信息的链路，不应新建链路。

  2)码流数据通道：用于网络实时音视频传输、网络录像回放、语音对话、语音监听、语音广播等。报文通信应新建链路，而不使用传输定位信息的链路。 

2.开发语言和架构设计

  语言的选择对于视频服务器的性能并不是决定性的,因为语言层面的性能的高低还轮不到我们一般的开发者指指点点,我们做的软件还不是阿里巴巴腾讯百度那种访问量级别的东西,软件出问题了,肯定是人写的有问题,你总不能对老板说这是由于我们没有采用某种牛逼的语言,没有采用某种牛逼的操作系统,其实我们都明白重要的是开发者自己是否对流媒体技术经验有长期的积累.但为了提高开发效率,避免重复造轮子,流媒体开发的第一语言首先还是c++.

  从协议中可以看出，视频的查看，需要平台下发给设备，完成一连串的指令交互，待指令交互完成后，由设备再和平台的视频服务器建立视频数据通道，开始传递视频数据。

  所以视频服务器需要两个服务器子系统，一个是视频的信令服务器，我们可以在部标808GPS网关服务器的基础上增加视频的信令和相关的逻辑处理、视频报警分析、视频参数设置等功能。对于流媒体数据解析这块，需要单独增加一个流媒体服务器，来进行流媒体的数据解析、编解码处理、录像存储、数据转发等工作。 

   开发一个高性能的完整的流媒体转发服务器，从架构设计上面分为五层：

   1）视频连接接入、管理、流量计算；

   2）RTP包数据解析，计算丢包率，提取音视频裸码流，根据RTP包的音视频类型格式，进行不同的编解码转换；

   3）转发层：根据用户端的播放请求和用户所能接受的音视频编码格式，匹配设备的音视频数据转发给指定的用户端，转发是视频服务器中最复杂的一环，不仅包括对企业平台用户的转发，还包括对上级监管平台用户的转发，两种转发基于不同的协议，需要做单独的处理。

   4）日志层：记录码流，记录音频数据为wav文件，方便进行调试； .

          5）界面层：进行视频设备连接监控和数据包监控

如需增加GB28181的视频转发功能, 可以参阅文章

GB28181协议和JT1078视频服务器的区别和集成

Netty4 + SpringBoot2 + RabbitMq + Redis + AliOSS 构建高性能粤标主动安全平台

如需购买部标1077视频平台或苏标平台，可联系2379423771@qq.com

基于此视频服务器可以开发1077视频平台或苏标主动安全平台：基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标视频监控平台

 在服务器端，内嵌了一个视频播放器，可以直接在视频服务器上面，双击视频连接查看视频，这样有助于调试设备视频。

    部标1078视频播放器

 

3.界面设计

视频服务器由于是接入全国几十家过检的设备厂商，不同的设备厂商采用不同的音频编码，视频数据流又非常庞大复杂，需要有非常友好的界面，方便设备调试，视频连接管理，丢包监控等。如下图所示，在视频服务器界面上能够做到以下监控：

1）当前的视频连接，音频编码，流量，丢包率，传输速度，时长；

2）可以查看某一个视频连接的RTP数据包；

3）可以监控当前的对讲和广播数据包；

4）对上级监管平台的转发数据包监控； 

 部标1078视频服务器界面

4.Html5播放器

视频服务器支持RTMP/HLS/HTTP-FLV/Websocket-FLV, 可以采用支持Http-Flv的Html5播放器 播放音视频数据. 

它的工作原理是将 FLV 文件流转码复用成 ISO BMFF（MP4 碎片）片段，然后通过 Media Source Extensions 将 MP4 片段喂进浏览器。

1) 具有 H.264 + AAC 编解码器播放功能

2) 多部分分段视频播放

3) HTTP FLV 低延迟实时流播放

4) FLV 也可以通过 WebSocket 实时流播放

5) 兼容 Chrome, FireFox, Safari 10, IE11 和 Edge

Html5 部标视频播放器

 

5.如需增加GB28181的视频转发功能, 可以参阅文章

GB28181协议和JT1078视频服务器的区别和集成

6.上级监管平台的转发

            对上级监管平台的交互，也是分为指令通道和数据通道，首先要基于809部分中的视频指令协议，完成视频指令交互应答后，为上级监控平台提供Http服务器接口，上级监控平台用户按照视频协议的HttpURL格式要求，发起Http请求，企业平台返回指定的设备的视频数据，上级监控平台获取数据后自行解码播放。

部标视频的压测文章参见：部标1077视频平台过检和压力测试经验分享

部标1078视频压力测试

(26558)

]]> http://www.jt808.com/?feed=rss2&p=1584 0 基于部标1078视频协议和苏标Adas协议构建主动平台 http://www.jt808.com/?p=1564 http://www.jt808.com/?p=1564#comments Sun, 03 Mar 2019 09:22:39 +0000 admin http://www.jt808.com/?p=1564  

苏标是江苏省交通厅发布的道路运输车辆主动安全智能防控系统的平台技术规范，现有的设备厂商如海康、经纬视觉、锐明，有为等厂商已经支持，都已经接入我的平台运营。苏标平台，依赖于具有主动安全终端设备，一般是通过加装特制摄像头或者雷达等外设来达到主动安全功能的。目前运营的效果来看，由于径卫视觉的设备比较麻烦，直接用的是博实结的部标视频1078模块，再加上自己模块，售后就经常需要博实结的人参与，两家一块找问题，维护起来就不是那么容易。

下图是海康威视的苏标主动安全终端设备的配置。

道路运输车辆主动安全智能防控终端设备参数表

 

如需购买苏标平台源码,请联系2379423771@qq.com

苏标平台架构设计参见文章:基于Redis + RabbitMQ的苏标主动安全平台架构设计

 

沪标主动安全平台系统架构和功能列表

 

Netty4 + SpringBoot2 + RabbitMq + Redis + AliOSS 构建高性能粤标主动安全平台

粤标主动安全平台主界面

 

主动安全协议-广东标准(粤标)和江苏标准(苏标)的区别及平台开发

 

如需增加GB28181的视频转发功能, 可以参阅文章

 

GB28181协议和JT1078视频服务器的区别和集成

苏标的主动性，在于通过视频算法分析，主动判断出司机驾驶行为是否违反驾驶行为规范，并触发报警，如前向碰撞报警、车道偏离报警、车距过近报警、疲劳驾驶报警、分神驾驶报警、接打电话报警、抽烟报警、驾驶员异常报警、胎压异常报警等。在发生报警的时候，可以上传违章证据到服务器平台，如视频，图片和记录仪数据等。

可以看到苏标平台，增加了大量的报警，每个报警还继续细分为一级和二级报警。企业安全监控平台应实现对车辆主动安全报警信息的实时处理，终端根据车速与报警参数将报警分为一级报警和二级报警，具体分级策略参见终端技术规范，平台接收到报警时应区分报警级别进行处理，具体措施如下：

a)  平台接收到一级报警时，应当记录报警信息并存档；

b)  如车辆在单位时间内上报一级报警达到一定数量，平台应产生一条驾驶员分神驾驶的二级报警。

c)  平台接收到二级报警时，应记录报警信息并存档，同时应以声音或图像的方式提醒监控人员。

苏标主动安全报警设置

与常规报警不同的是，苏标Adas报警在产生等级较高的报警的时候，会在终端产生报警时主动记录前后几秒钟的视频录像文件，拍照和行车数据文件，上传给平台后，又有体积较小，可以快速的传递给平台。一般在报警的时会产生7个附件，三个图片，三个通道的mp4录像文件，一个记录仪的二进制文件。苏标协议要通过附件指令，要求设备按照苏标的附件上传协议，上传附件到指定的服务器接收，所以必须要开发一个专用的苏标附件服务器，这个服务器的职责就是解析附件数据，附件协议的复杂性在于附件的高频上传，一次报警会产生N个文件列表，当车辆规模达到一定程度的时候，在同一秒，对于一个普通的万辆车规模的监控平台，将可能有几百辆车在同时报警并上传附件数据，特别是像车道偏离这样高频报警，对附件服务器的解析性能，存储性能都有极大的挑战。

苏标报警附件

 报警的时候，将会产生比GPS定位记录还有多的数据，一次报警，将会产生至少一个报警记录，四到7个附件记录。

       苏标协议附件上传

附件上传完毕后的消息推送，可以采用ActiveMQ, 或RabbitMQ的消息队列，将附件数据和报警信息糅合成一个苏标报警消息快速的传递给前端展示。所以苏标报警信息的展示的信息量是很丰富的，有文字，图片和视频同时展示给用户。如需购买平台源码, 请联系2379423771@qq.com

苏标主动安全报警

        苏标设备产生的数据、报警关联的报警附件等也需要通过809协议上传到运管平台上面去，为此苏标也对809协议进行了扩展，增加多个指令，以支持企业平台上传报警文件和报警消息。

       

 

        所以一个主动安全平台，本身是一个三合一的平台，包含了GPS、视频和主动安全三大功能体系以及相互联动衍生的功能，所以架构也更加复杂，在后端服务器模块，需要构建同时  兼容部标808协议指令、视频1078指令和苏标协议指令的网关服务器、部标1078视频服务器和苏标Adas服务器等多个子系统。苏标在部标1077视频平台基础之上，又额外提了对于主动安全、驾驶员考核与分析的新的功能要求。

       由于苏标协议已经运行一年多, 从设备厂商到平台软件开发者对于苏标的支持力度都很大, 苏标协议标准实际上已经成为其他各省仿效的标准, 目前陕标和川标浙标都是直接拿来主义,  将苏标作为自己的标准使用,  设备厂商从开发成本的角度也不可能原因每个省都标新立异搞一个自己的标准, 目前全国各地基本上在主动安全上面, 都已经将苏标标准作为一个核心标准, 在第三方平台接入\设备接入\招投标方面, 都是以苏标文档中要求的功能标准和协议标准作为门槛准入的最低条件.

苏标主要的功能列表如下所示：        

1企业安全监控平台功能

1.1  基础功能

企业安全监管平台基本功能应满足JT/T 796 中第6章描述的所有功能。

1.2  扩展功能

1.2.1  用户管理

第5章5.2 用户管理中描述的功能。

1.2.2  报警类型

企业安全监控平台应支持接收由主动安全智能防控终端触发前向碰撞报警、车道偏离报警、车距过近报警、疲劳驾驶报警、分神驾驶报警、接打电话报警、抽烟报警、驾驶员异常报警、胎压异常报警等。

报警信息实时监控及处理

 

a)  平台接收到一级报警时，应当记录报警信息并存档；

b)  如车辆在单位时间内上报一级报警达到一定数量，平台应产生一条驾驶员分神驾驶的二级报警。

c)  平台接收到二级报警时，应记录报警信息并存档，同时应以声音或图像的方式提醒监控人员。

企业安全监控平台应能够存储平台内车辆的主动安全智能防控相关信息，报警信息包含报警类型，报警等级，报警开始时间，报警结束时间，报警时车速，经纬度，高程。

1.2.4  报警查询

 

a)  支持按驾驶员查询报警信息。

b)  支持按车辆牌照查询报警信息。

c)  支持按照报警类型、报警等级查询报警信息。

d)  支持按时间段查询报警信息。

e)  支持对所查询报警信息相关音视频、照片证据的回放及导出。

f)  支持查询信息报表生成功能，生成包含查询时间段、查询发起方身份、详细报警信息等在内的查询报表，并应支持报表的导出功能。

1.2.5  报警信息统计与分析

 

a)  支持对企业报警类型进行统计分析，可直观展现各种类型报警变化趋势和相对比例。

b)  支持对企业内驾驶员关联报警进行分析，可形成驾驶员驾驶行为统计报表。

c)  支持对企业内车辆关联报警进行分析，行成车辆报警统计分析图。

1.2.6  驾驶员档案管理

企业安全监控平台应当设立驾驶员档案库。支持将驾驶员信息录入驾驶员档案库的功能。驾驶员档案库信息应包含驾驶员个人信息、驾照信息、正面照等相关信息。

驾驶员分析

企业安全监控平台应支持根据驾驶员相关驾驶行为数据、百公里报警数据对驾驶员驾驶行为进行综合分析及评价的功能，平台应能够按照相应指标对驾驶员驾驶行为进行周期性评分，评分结果应能保存到驾驶员档案库中，平台用户可按照不同标准对驾驶员评分进行排序、筛选操作。

1.2.8  车辆终端信息管理

企业安全监控平台应当支持对主动安全智能防控终端安装信息的管理。所有入网车辆所安装的主动安全智能防控终端品牌及型号应当在企业安全监控平台中详细记录。平台应支持按照车牌号、所安装主动安全智能防控终端的品牌型号等条件查询相关车辆信息，且支持对于车辆安装信息的更新、修改及删除。

1.2.9  接收信息与展示

企业安全监控平台应具备接收政府监管平台下发的信息，并能够提示企业管理人员。

1.2.10  终端在线升级

企业安全监控平台应支持对车载终端的在线升级推送功能，当有车载终端软件升级包时，平台向终端发起在线升级指令，终端根据平台提供的升级包下载地址获取升级包进行自动升级，并在升级成功后向平台发送升级成功指令，平台同时记录升级后的终端软件版本信息。

平台支持在线升级策略管理，包含单位批次数量、定时升级任务以及选定设备手动升级等功能。

1.2.11  驾驶员身份识别功能

企业安全监控平台应支持人脸识别功能，当车载终端发送驾驶员身份识别指令时，平台应根据指令上报的驾驶员IC卡号以及驾驶员照片进行比对，当驾驶员IC卡与驾驶员不对应时，则平台记录一条驾驶员身份不匹配的报警信息，同时提醒企业监控人员进行处理。

当上报的驾驶员照片信息无法识别，则平台提醒企业监控人员进行人工核对。

(23392)

]]> http://www.jt808.com/?feed=rss2&p=1564 0 部标1077视频平台过检和压力测试经验分享 http://www.jt808.com/?p=1448 http://www.jt808.com/?p=1448#comments Mon, 23 Jul 2018 01:13:37 +0000 admin http://www.jt808.com/?p=1448 部标1077视频平台标准是在2016年10月份发布的，2017年1月1日开始实施，由于两客一危行业车辆如果做视频运营，必须要通过1077检测，所以现在两客一危平台检测默认是包含部标796GPS平台检测和部标1077视频平台检测。当然现在已有的两客一危平台肯定已经通过了部标796GPS平台的检测。但是对于市场新进入者，部标1077视频平台不能单独过检，需要先过部标796平台检测，通过796平台检测后，才能再进行部标1077视频平台检测； 虽然视频平台检测相比GPS平台检测，要多一个视频压力测试，但是视频平台的检测费用上面相比796平台过检，价格略低，检测费是3万元。796平台检测费是3.8万。不过如果以前没有过过796，则两次检测报名费用合计是6.8万。

796平台检测和1077平台，如果是不同的平台，架构必须要一致，796是BS网页版本的，则1077视频平台也必须要是BS网页版本的，不能是CS桌面版本的。 由于很多厂商老旧的视频平台都是桌面客户端程序，不是真正意义的BS网页版本的程序，所以不得不做成假的BS程序，通过ActiveX控件，只能使用低版本的IE7,8，9等，依赖IE减低安全等级设置。所以如果是开发平台，最好是一步到位选择真正的BS网页架构版本的平台。 

BS版本架构的部标1077视频平台参见：

1、基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标GPS和部标视频监控平台

 

2、基于JT/T 1078协议设计和开发部标视频服务器

视频平台检测的主要难点是压力测试，主要的流程如下： 

相对于796平台检测的压测的主要区别是：

1.gps压测相对于796多了1000台，压测结果是对比发送的和接收的是否一致，一条也不能少；

2.gps压测通过后，3000台车保持在线，但停止发送定位，开始视频200辆车压测；

3.视频压测的时候，200路的视频连接和对应的200路上级监管平台的转发连接都保持稳定后才开始统计码流；

如果不够200路，压测直接就失败了，因为没有码流统计数字，无法统计结果；

4.200路转发成功后，任意选择一路播放视频，如果有黑屏，卡顿或者无法打开播放的情况，则视为失败；

5.视频播放的时候如果声音不连续也不行，这也说明了卡顿；

6.测试卡顿使用的视频，是一个座钟秒针转动的画面，如果有卡顿，秒针走的时候也会一顿一顿，很明显能够看出来。如果有丢包或者跳帧，则秒针就会时快时慢，或者跳跃前进。

7.测试30分钟，然后统计终端发送的码流，和上级监管平台接收的码流，两者的数字相加要大于11M。视为压测通过。

8.统计结束后，截屏上传到检测系统当中，生成压测报告。

 部标1078视频压力测试

压测的时候，对于带宽的要求显然要高于796平台的检测要求。

播放视频的时候，播放的那一路最好不要断开连接，否则容易出现卡顿或者黑屏的情况；

交通部测试终端的出口带宽感觉在100M一下，在家里做测的时候，用10M带宽对100M服务器测试的时候，2分钟3000个连接都建立了。在交通部测试的时候，需要3,4分钟才建立完毕。

码流统计标准，之所以设计为11M，估计是一个经验值，200路如果每一路都保证画面播放流畅，则码流必须要良好才行。进而累计200路的码流值必须要是一个合理的数字。

总之要想过检，压测是重中之重，必须要认真对待。

视频平台的检测难度无论从功能细节上面还是压测强度方面，都是要高于GPS平台检测的，本平台已经通过部标1077视频平台检测，提供有偿收费检测服务，如需购买源码或购买代理过检服务，请加QQ：2379423771，注明购买源码或购买部标过检服务；我不是销售，作为一个忙碌的开发人员哪里有时间在网上瞎扯淡，目前只针对真正想降低成本，提高效率，诚意购买的人提供服务。

压力测试结果后，会打印压测数据结果，存档备案，压测结果如下图所示：

部标1078视频压力测试报告

我是提供源码的，少走弯路，降低成本对公司是好事情，光明正大的给公司申请下有什么不好，自己开发，无论你多牛逼，你都绕不过漫长的开发周期和测试稳定周期，公司也必须要承担长周期带来的不可预估的失败风险和高昂的开发成本，只有血气方刚没经验的新手才会给自己或者公司挖坑，要么没有时间观念无所作为每天荒废于互联网搜索免费资源当中，要么设定激进的开发进度计划和交付时间点，给自己以极大压力。时间是后知后觉者的高昂的成本，也是市场先行者构筑竞争的砝码和壁垒，购买源码，在短时间就拥有了视频平台开发技术，瞬间有一个较高的起点才是上上之策。

很多团队为什么宁愿让公司置于项目不断延期的风险之中，就在很多负责人都是技术人员出身，过于理性，做事思虑过多，瞻前而顾后，多谋而不善断，格局太小，只关注局部的成本开支，不以完成交付为第一目标，不重视项目高效推进落实，听不得收费服务，一听到要收费就痛苦的不得了，自己都不想想自己一个月多少工资成本，自己团队一个月多少工资成本，随便一个项目，几个月都难以交付，其实作为每个月要支持高昂开发成本的软件公司，在开发上是不能慢下来的，必须要杀伐决断，立即行动。我提供的平台代码和技术支持可以让技术团队快速聚焦，不再东一榔头西一棒槌，而是脚踏实地，拧成一股绳向前推进。

 

1077视频平台检测

(17328)

]]> http://www.jt808.com/?feed=rss2&p=1448 0 基于Html5+HLS协议播放符合部标1078协议的实时流媒体视频 http://www.jt808.com/?p=1401 http://www.jt808.com/?p=1401#comments Tue, 05 Jun 2018 11:33:38 +0000 admin http://www.jt808.com/?p=1401     由于现在主流的部标GPS和1077视频监控平台，都是BS架构，在网页上播放视频，早期的很多平台用的都是ActiveX控件的形式，依赖于IE浏览器，需要降低浏览器的安全设置，而且非常难用。同时由于win10以后的操作系统上的浏览器，对于安全的把控非常严格，ActiveX插件做成的播放器嵌入到网页当中的形式，基本上要被扫入到历史的垃圾堆里面了。

    HTML5虽然日臻成熟，VIDEO标签，可以播放服务器的视频文件，实现了真正的网页播放视频，但是原则上只能播放服务器上面的文件流，不能播放实时的视频流, 也就是不支持常说的live streaming。

   不过，HLS协议出现了，而HTML5是支持HLS协议格式的。通过HTML5 + HLS实现了网页实时视频监控的功能。

   HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)playlist文件，用于寻找可用的媒体流。

HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。

  所以实时模式下，HLS就是实时生成M3u8文件和ts文件。它的索引文件一直处于动态变化的，HTML5播放的时候需要不断下载二级index文件，以获得最新生成的ts文件播放视频。

     如果想让HTML5播放器支持部标1078协议的视频，其实本质上就是协议数据格式转换，由于部标JT/T 1078协议文档中，视频编码格式仍然是H.264, 但对于实时的音视频进行了RTP包的封装，也就是按照RTP协议传输视频数据，需要开发流媒体服务器，接收RTP包，并提取出音视频的h.264原始数据流，然后将实时的数据流，按照HLS协议格式，实时切片，转换成HLS协议格式的数据就可以了。

如需购买符合部标1077功能标准和部标1078协议标准的B/S架构的平台，请参考文章：

 1）Asp.NET版的部标平台开发-》基于Asp.NET MVC构建BS架构的GPS视频部标平台

  2)  基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标GPS-视频1077监控平台

3) 部标1077视频平台过检和压力测试经验分享

4）基于部标1078视频协议和苏标Adas协议构建主动安全平台

5) 基于JT/T 1078协议设计和开发部标视频服务器

     在部标1078协议的RTP包格式中，可以获取到设备的Sim卡号和逻辑通道号，服务器在切片的时候，就可以用Sim卡号和逻辑通道号作为HLS协议中的M3u8索引文件的文件名，如设备的Sim卡号是013200000008，通道1的视频，切片的时候，索引文件就是013200000008_1.m3u8。这样在web端播放视频的时候，双击车辆的通道的时候，就可以设置VIDEO标签的src属性为这个索引文件名就可以播放指定车辆的实时视频了。

    <video src="013200000008_1.m3u8" controls></video>

 

1078视频服务器架构

     

    

(14213)

]]> http://www.jt808.com/?feed=rss2&p=1401 0 锐明部标视频设备和博实结设备对部标1078协议支持程度评测对比 http://www.jt808.com/?p=1350 http://www.jt808.com/?p=1350#comments Wed, 31 Jan 2018 03:08:56 +0000 admin http://www.jt808.com/?p=1350 我的一个客户，现在需要上线部标视频设备，但是对于锐明和博实结两家的视频设备，不知道哪家对部标1078协议支持的更好。希望我能帮他测一测。

对此次评测结果的总结：

1.部标视频协议的支持程度，锐明和博实结支持的都比较糟糕，不知道他们是怎么过检的，大面积的不符合1078协议指令，锐明还是第一批过检，也是部标1078协议标准的起草单位之一，自己参与撰写的自己都支持的不完善。博实结开始只给客户看证书，没有量产设备，从GF-01到GF-02,给客户换了两次设备，都测试有毛病，最后还要换设备，客户也没耐心了去他妈的换货不换了也不用了。车载视频做的最好的几家公司，主要是在视频领域有一定研发积累，研发实力较强的，比如海康、大华等几家浙江的上市公司，锐明和这两家比起来还差点，但在车载领域做的还可以。博实结只是在GPS上做设备，做视频还很弱。视频设备的研发还是需要有一定的实力积累的，如果仅是买了块板子，用了几个海思芯片SDK开发包，就像你用百度SDK包开发地图一样，技术能力肯定比不上专业搞GIS地图的，后劲肯定不足，技术细节处理不到位，处理问题的能力也很差。

    1）在部标1078协议中，对于终端参数设置和查询，增加了大量的音视频参数设置，这块锐明和博实结的都没有支持，也就是说还无法通过部标参数设置命令，设置视频设备的音视频参数,特别是码流，字幕叠加等功能，都无法通过远程设置，给锐明售后反馈过，这块锐明的研发速度特别慢，一直到现在大半年了也没有新的版本支持。

    2） 视频报警这块，视频报警也是在部标0×0200定位包中，进行了扩展，增加了视频丢失、视频遮挡还有ADS驾驶行为等指令，可以监控到各个视频通道的摄像头状态，但是这块锐明和博实结都没有完整严格的按照部标1078协议进行支持。无法在平台上展现各个通道的状态。

   3） UDP协议支持方面，部标要求TCP和UDP，终端都应该支持，但博实结不支持UDP协议传输，锐明的设备TCP和UDP都支持。我们知道流媒体协议传输的时候，由于由于UDP的传输时延低于TCP，能与视频和音频很好匹配。因此，在实际应用中，RTP/RTCP/UDP用于音频/视频媒体，而TCP用于控制信令的传输。 

   4）FTP上传， 博实结和锐明的都支持FTP上传，博实结的文件格式.avi格式，用常规的播放器都可以播放。锐明的是.264格式，264格式不符合部标1078协议要求，部标要求格式是avi或mp4格式。另外博实结FTP上传的指定文件目录名的时候，有一个明显的bug。

       锐明对于FTP上传的支持也有很大的缺陷，仅仅支持上传，但上传过程中取消不了，不支持0×9207文件上传控制指令，上传完毕后也不发送0×1206文件上传完成通知指令，结果就是服务器无法知道上传是否成功或失败。

   5）录像回放这块，锐明的不支持跨天回放，只能在当天时间段内回放，竟然不支持1078协议中要求的快进，快退回放这种视频监控中的基本功能。

   6）部标1078协议要求终端对平台下发的指令，都要给予应答。目前博实结的GF-02设备存在严重bug，收不到应答，导致平台无法判断指令是否正确执行；

   7）博实结和锐明的设备，都不带RJ45网口，这点就不如大华的设备方便，导致测试的时候，不能用网线连接，必须要插卡测试，浪费流量。WIFI是外置插件，需要单独购买，非常不好用。

   8）两家用的芯片是一样的，所以音视频编码都是一样的，视频是h.264编码, 音频编码是ADPCMA编码。

   9）两家都有自己的软件平台，功能非常弱，虽然是设备厂商，重心不在这里，但是两家的平台也有客户，也不应该如此的糊弄，一个平台仅仅能放个实时视频，其实视频功能多了去了。

2.技术支持服务，因为测试时锐明问题很少，没有和锐明技术服务体系直接打过交道，无法对比。博实结的从购买GF-01设备开始到最后客户终止购买，从17年10月24日，到最后18年1月29日，处理周期是3个月，时间大部分耽误在查找问题，来回物流快递设备换货上面了（换货时必须要先退货那边收到后才发新货）。要是你在参与项目市场竞争，估计菜都凉了。

3.两家设备价格一模一样，裸机对外报价暂时都是1300元，没有价格优势对比，配件中普通摄像头和高清摄像头价格有差异，没有可比性，锐明多了个70元钱的运维宝，不过可以不用。

4.设备质量，运行稳定性上面，没有经过上路测试和实际运营，无法给出对比，这个也不是我搞软件平台开发的职责范畴。博实结的设备问题到最后撕破脸也没查出问题，或许研发知道但不告诉你。他们惯用的招数就是换货。很多人觉得换货就很满足了，这在车载终端领域，换货的成本要多高，很多人都是无知的状态，一台设备安装到车上，人工安装成本、差旅成本是多少？ 然后再拆下来，拆卸成本是多少？ 需要发回原厂，物流成本是多少，然后对方再发货给你（需要注明的是厂家发货，运费都是到付，快递到付的成本比现结的成本要高很多），最后你重新再安装上去，整个处理过程的周期是多长？ 这么长的时间成本是多少？通过这几个问题，你应该知道换货的成本有多高，而设备厂商呢就是发了一个设备而已，还是到付。

 

如需购买符合部标1077功能标准和部标1078协议标准的B/S架构的平台，请参考文章：

 1）Asp.NET版的部标平台开发-》基于Asp.NET MVC构建BS架构的GPS视频部标平台

  2)  基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标GPS-视频1077监控平台

3) 部标1077视频平台过检和压力测试经验分享

4）基于部标1078视频协议和苏标Adas协议构建主动安全平台

5) 基于JT/T 1078协议设计和开发部标视频服务器

jt1078视频服务器

下面说下两个设备的评测的详细过程：

客户首先给我的是博实结的一款设备GF-01的设备，博实结的销售说是支持部标1078协议的，经过我测试，发现报文还是博实结的私有协议，我告诉了客户，他还不信，说博实结的销售给他说这款是过检的设备。还展示证书给我看。我说这款设备完全不支持部标。加了他们的技术支持，他们的技术支持开始还不敢承认此事和担当责任，让我们客户从销售买的自行去联系销售。

部标设备

最后承认设备不支持，后续答应给升级，至于什么时候能升级能出来就不知道了。问有没有最新支持部标1078协议的视频设备，答复是没有。客户虽然很愤怒，但也没办法。因为只买了一台，犯不上和他们较劲，虽然想投诉他们的销售，但是他们的网站上也没有投诉的入口，也没有投诉电话。

过了一个多月，因为不想这个设备报废，就又联系博实结的技术支持，他们捣鼓半天，回复说这个设备GF-01的设备，升不了级，不过答应说给更换一台GF-02的设备，说是GF-02的设备符合1078协议。客户没办法，自己掏腰包把设备顺丰快递到深圳，然后那边收到退货设备后，他们用了个最慢的快递宅急送给送过来了，一来一回又小半个月过去。

GF-02设备接电，连接到我的部标1078视频服务器上面，测试发现服务器下发的所有的1078协议指令，都没有收到终端的应答，而下发808指令如拍照、查询终端参数等，可以收到终端的应答。搞开发的都知道，这明显就是个bug。而这个明显的bug，竟然和他们纠缠了好多天，耽误了我宝贵的开发时间，让我极度恼火，最后也让我撕破脸在QQ上怼了他们领导。我还原一下和他们纠缠的过程，让大家深刻理解这个过程又多艰难。

收不到设备应答

说别人有问题，首先要确定自己是干净的没问题的，第一步就是记录原始报文，看看报文里面有没有终端上来的1078应答，结论是没有终端应答。第二部是用wireshark, 抓包，结论也是没有。第三步，确定平台下发指令是正确无误的，其实基于部标协议，如果下发指令是不正确的，终端都必须要应答，回复终端指令不正确或者不支持。通过分析指令，确定指令是正确无误的，因为设备在收到指令后确实是执行了，但就是没有回复应答，这样服务器无法知道指令是否成功。因为客户手里还有锐明的最新款的部标视频设备D5M，上电连接后，下发指令完全支持。

首先对锐明的设备，下发各种1078指令，服务器都正常能收到应答：

 

联系他们的技术支持，他们在设备上抓取报文后，发现有设备有应答的日志，然后就坚持认为设备没有问题，我说这个逻辑不成立，设备有没有发送应答，应该以平台是否收到为准，你的设备记录了日志，不代表你最后成功发送出去了。为了这个逻辑，反复纠缠，最后他们才答应联系他们的3G终端开发人员，成立了一个群。没有人给你反馈这个问题，他们内部各个部门好像谁都不愿意联系谁，你还要自己重新和群里的人，再重复一遍问题的现象，再贴图，再说明其他厂家的设备，都没有此问题，他们好像也不听你的，仍然又回到原点，他们说设备有日志记录，设备没有问题。

最后他们同意再接一台设备到我服务器上验证此事，结果他们接的那台设备是正常的，这次他们稍微重视了这个问题，后面又升级折腾了一天，客户的设备还是不行，就是没有应答。他们自己实验室的设备究竟和我客户手里的设备有何不同，他们也没有说明。

他们的一个经理装模作业的答应换货，还精描淡写的说前面的工作都是他们配合我的，我一下子怒了，出了问题，自己不主导各个部门去解决问题，让我一个陌生人自己从销售到支持服务，到研发工程师，每个衙门都要转一圈，每个地方都要重新说明一遍问题，反复纠缠，他们就简单拉了群，还是是为了配合我，难道还要我感谢他们?

因为耽误了我好几天的时间，我情绪失控，在QQ上怼了他们的一个小经理的领导，由于我的情绪失控的代价就是，他们在他们也不换货，也不退款，设备算是白买了，好在就这一台设备，不买他们家的设备就行了。

后面我又测试了一些其他的设备功能，还有一些问题，因为客户不打算用他们家设备了，也就此打住了。

锐明的设备，我测试了一遍， 在指令上支持还是相对比较完善，不过也有小的瑕疵，在部标1078协议中，对于终端参数设置和查询，增加了大量的音视频参数设置，这块锐明和博实结的都没有支持，也就是说还无法通过部标参数设置命令，设置视频设备的音视频参数，另外一个就是视频报警这块，视频报警也是在部标0×0200定位包中，进行了扩展，增加了视频丢失、视频遮挡还有ADS驾驶行为等指令，可以监控到各个视频通道的摄像头状态，但是这块都没有支持。无法在平台上展现各个通道的状态。

 

教训总结：

1.由于博实结没有自己的部标1078视频调试服务器，无法在他们的服务器端看到原始报文。本来这块问题很简单，我只需要把设备接入到他们的视频服务器上，能不能收到应答，一下子就看出来了，结果呢他们只负责看终端，这块让我对他们的视频研发实力很是怀疑。没有1078视频调试服务器，他们是怎么调试终端程序的，怎么交互的，我很难以理解。如果没有调试服务器，他们的测试肯定不方便，就不可能进行充分的测试，必须会有问题出现，这是IT开发的规律。就像你是羽毛球选手，没有陪练的一样，你的水平高低自然可知。

2.和公司做生意，如果有问题，最麻烦最头疼的就是在商务销售、技术支持、研发部门绕来绕去，互相推诿，没有担当，没有人给你出头，把这个事情给你解决了，需要你自己挨个联系，经常是你口干舌燥的说完问题（为了把问题说清楚，必须要长篇大论），他告诉你，你去联系谁谁谁。经过此事，我唯一得到的是了解了博实结的处理的组织架构。

3.博实结这件事最没担当最混账的就是他们的商务，先是在没有部标1078设备量产的情况下，欺骗客户购买了GF-01的设备，不符合标准后，说是给升级，到后来又说不能升级，最后换来的GF-02 设备还是有毛病，他不负责，不去协调自己内部各个部门去解决问题。

4.博实结公司，没有投诉反应他们人员问题的入口，这些人的行为得不到惩罚，问题只能继续存在下去，得不到解决，由于得不到任何的惩罚处理，他们也绝不会意识到错误，没有人觉得事情这严重，都是云谈风轻，轻描淡写的，谁管你Y的是干啥的。这件事由于客户幸好只购买了一台GF-01设备，没有造成更大的经济损失，试想如果大批量购买了GF-01设备，并安装上车，怎么退货更换？ 客户的客户都饶了客户吗？

(18233)

]]> http://www.jt808.com/?feed=rss2&p=1350 0 基于spring4+springMVC4+mybatis3+Hibernate4+junit4框架构建高性能企业级的部标1078视频监控平台 http://www.jt808.com/?p=939 http://www.jt808.com/?p=939#comments Sat, 06 Aug 2016 02:48:43 +0000 admin http://www.jt808.com/?p=939   开发企业级的部标GPS监控平台，投入的开发力量很大，开发周期也很长，选择主流的开发语言以及成熟的开源技术框架来构建基础平台，是最恰当不过的事情，在设计之初就避免掉了技术选型的风险，避免以后在开发过程中，不断的填坑走弯路，以至于整个团队被坑埋掉。做GPS平台这么多年，以前就了解到一些开发团队过于关注某一种语言的优势，比如过于选用GO，Erlang，python,php等技术，最后团队熟悉这些技术的关键人员离职了，都没人接手，不能不说是个悲剧。所以说平台的技术架构选型要注重的是稳健，均衡而不是偏激，而SpringMVC4, Mybatis4, Hibernate4就是GPS监控平台软件开发的理想框架选择。

本版本是2015-2017年推出的最新稳定版本，是我工作的主流版本，相对于原来的2014年研发的旧版的struts版本，从性能和功能上有了较大的提升，融合了大量客户的需求意见，特点：

1）SpringMVC版本已经替代struts成为主流框架.

2）采用Netty框架替代原有的Mina框架，在服务器的并发性能上有了大幅提升，普通服务器单进程可以支撑到3万台终端；部标808服务器所支持的部标协议，旧版只支持jt/t 808 2011版本的协议，新版本全面支持jt/t 808 2013版本的协议，如定时拍照等新特性，增加了808协议数据实时转发的特性。

3） 采用Redis缓存服务器，支持多台808服务器集群，参见文章：基于Redis构建10万+终端级的高性能部标808Gps网关服务器

4）可以接收第三方的转发的数据，由于很多GPS平台所获得的数据都是从第三方平台而来，并不能得到一手的GPS终端数据，809模块增加了809政府运管服务器，用来接收第三方转发而来的数据。

5）采用Mybatis替代旧版本中已经淘汰的Ibatis框架，通过Mybatis的查询分页插件，可以很方便的支撑各种数据库的分页查询，代码可以支持Mysql, Sqlserver, 和Oracle三种数据库，利用Mybatis的批量插入特性，大幅提升了GPS数据入库的性能；

6）地图部分做了较大的优化，统一地图接口，支持百度、高德和四维三种地图；

7）新版本是基于saas的多租户架构设计，充分支持多公司，多集团，多代理的组织架构模式，不同企业实体的数据、权限进行完全的隔离，可以单独为每个企业分配企业管理员，企业管理员在自己的企业实体内，可以单独分配角色权限，建立部门和车队；

8）Spring框架从旧版的2.5升级到Spring4, 从原来的全xml配置，利用Spring4的注解特性，大幅削减了系统的xml配置，系统部署和配置更加方便，维护更加容易；

9)  SpringMVC4集成WebSocket，基于Websocket进行报警推送，大大提高报警推送的效率。

参见：基于Websocket+SpringMVC4推送部标Jt808终端报警

10） 使用阿里巴巴团队开源的Druid连接池，Druid是Java语言中最好的数据库连接池。能够提供强大的监控和扩展功能。

11) 对原有的代码做了大量的优化，性能做了较大的提升，代码进行了充分的重构，增加了大量的注释，设计文档进行了重写；

12) Android客户端跟随最新谷歌主流的Material Design设计思想，采用android studio和gradle3.0做开发工具，使用主流的框架retrofit 2.0网络库等框架开发，保证代码使用的是最新的主流技术，方便技术团队对接和消化。

13) 部标GPS平台可以单独付费升级为部标1077视频平台，支持符合部标视频Jt/t 1078协议标准的部标1076视频设备接入，在BS端通过HTML5 Video插件或者flash插件进行实时视频监控和录像回放、视频文件下载。

14）基于苏标Adas协议构建主动安全平台

2017年至2018年，主要做的重大版本更新有：

1.2017年增加部标1078协议支持，增加部标1077视频监控平台功能支持，相继有多家客户通过交通部过检机构中心的部标1077视频监控平台过检与认证,拿到了报告和公示；

2.2018年增加对江苏省的Adas标准的支持.

2019年主要做的重大更新：

1. 更新平台功能符合国标GB/T 35658-2017标准，新标准做了大量的增补, 由于《道路运输车辆卫星定位系统 平台技术要求》由部标796标准变为国标GB/T 35658-2017标准，信息中心的测试标准也按照GB/T 35658-2017标准来检。

   参见文章:GB∕T 35658平台过检 已通过最新的部标JT/T 808-2019, JT/T 809-2019标准 

2.基于部标1078视频协议和苏标Adas协议构建主动安全平台

 

基于Redis + RabbitMQ的苏标主动安全平台架构设计

通过增加1078视频服务器和web视频播放器，可以将GPS平台改进为符合部标1077的视频平台。当然视频开发的工作量和复杂度也是gps平台所不能比的。一个视频平台不是简简单单的播放视频就完事了，仔细阅读部标1077的文档的视频功能标准就可以看到，一个视频平台还要附加大量与视频相关的如视频报警、报警联动、服务器录像存储回放、视频参数设置、视频下载、报表统计等功能，有很多琐碎的功能细节需要全部实现，才能称为一个完整的部标视频平台。同时视频平台也需要与上级运管对接，为上级运管提供视频转发的服务器功能，1078协议在809协议上面又附加了大量与视频相关的指令，如实时播放、FTP上传、资源文件检索、回放、报警等功能。

GPS平台有了视频功能，平台监控手段地丰富性将大大增强，GPS报警，轨迹，报表等都可以和实时视频，视频录像文件进行深度的集成和关联，如视频报警联动等，如下图所示：

苏标主动安全平台主界面

 

历史轨迹回放和视频回放的结合：

jt/t 1078协议历史视频回放指令和功能

部标1077平台的核心是两个服务器模块，部标808网关服务器和部标1078视频服务器，其中部标808gps网关服务器提供指令服务，部标1078视频服务器主要为用户客户端提供基于RTSP协议标准实现的嵌入式的RTSP服务器功能，处理用户的RTSP视频实时播放和历史视频回放请求，还有流媒体服务的核心功能，如音视频的编解码和流媒体转发处理的核心模块，另外还有服务器连接管理，录像，下载，流量计算等附加功能。

jt1078视频服务器

 

如需购买，可以联系2379423771@qq.com, 本人可以去客户所在地，提供两天以内的免费培训和技术支持服务（差旅住宿费用由客户承担）。

 

旧版的基于struts2技术框架的平台源码仍然销售，但不再提供升级，参见基于Struts+Spring+Hibernate+Ibatis+Quartz+Mina框架构建部标监控平台

.NET平台，参见：基于Asp.NET MVC构建GPS部标平台

废话少说，我们现在构建基于BS网页Web模式的部标GPS监控平台，基于主流的J2EE三层模型，主要的技术选型如下：

1.基础容器框架 spring4

2.Web框架 Springmvc4

3.ORM实体与关系数据库映射框架 hibernate4

4.SQL查询框架 mybatis3

5.单元测试 junit4

6.日志   log4j

7.定时任务框架Quartz 

系统运行环境：tomcat7+ 、JDK7+、MySql 5.7/ SQSERVER2005/Oracle9

 

GPS监控的web平台对技术的要求如下：

1.实时监控和部标808协议的几十种终端指令的上传下达，百度地图车辆位置监控，地图操作等功能需要频发的对服务器发送基于ajax的request，返回json数据，基本上是重度使用ajax请求和Json传输。

2.Web服务器需要应对网页客户端重度的request请求，性能要求较高，在mvc框架开发的时候，一定要避免内存泄漏，因为在频繁的request请求调用之下，小小的内存泄漏，会一点一点积累，直至耗掉tomcat的内存。

 

 

Web框架我们采用sprngMVC4， 主要的考虑如下：

1.全注解环境，采用springmvc4，替xml配置，避免掉了一大堆的xml配置，对应URL的映射和request参数的映射直接在方法中通过注解配置；

2.spring mvc是基于方法的设计，controller是单例模式，而sturts是基于类，每次发一次请求都会实例一个action，每个action都会被注入属性，而spring基于方法，粒度更细，性能上更高一筹；

 

数据库ORM的框架要求如下：

1.能够比较灵活的适应主流的数据库，如mysql, mssqlserver, oracle等，现在的开发团队和开发人员在开发的时候，几乎没有人关注这个问题，基本都是在一个数据库上吊死，而作为一个平台的开发，为应对不同的客户要求，团队的开发力量有限，不能一个数据库一个版本，这样开发和维护、升级、测试成本就急速的升高，所以我们追求的是一下几个原则：

1）不用存储过程和触发器；

  很多开发团队都是重度的存储过程和触发器的使用者，连简单的查询分页都要用存储过程，一旦开发人员离职，这些存储过程和触发器都像天书一样，难以维护，一般我们的代码都是在SVN基于配置库进行版本管理，而存储过程和触发器却脱离这些之外，存储过程和触发器如果有bug出现问题，在生产环境上，很难进行跟踪，web容器的日志记录只能跟踪到java代码级别，剩下就需要DBA来配合了。

2）使用Hibernate4 框架，实体类和数据库的映射都在类和属性方法上完成；基于Hibernate的配置就可以轻松切换到其他数据库。

3）采用采用Mybatis的物理分页插件，通过拦截器的方式，在开发人员编写的SQL上进行拦截，并自动包装上各个数据库的物理分页代码，可以支持多个主流数据库的物理分页查询方法。

4）采用mybatis和log4j，可以很方便的打印SQL日志，方便调试跟踪。

 

5）采用阿里巴巴的开源连接池引擎，配置对spring service层的AOP监控，druid内置了后台监控页面，可以直接监控连接池的耗费情况，以及SQL的性能耗时监控，非常方便。

808服务器连接池监控

基于Maven构建多模块项目工程，打造干净的依赖库

  我们在开发GPS监控平台的时候，一般都是基于业务功能和职责，将业务分为多个模块，各个模块之间相互独立，每个模块可以独立运行或者作为独立的公共类库被其他模块所依赖如Dao、Service等。

  实际上一个部标GPS监控平台，里面包含了多个业务功能模块，如部标808GPS服务器，web网页客户端，809转发服务器，移动API，位置服务，计算服务等等。

  由于多个模块，都需要依赖这些开发框架，而开源框架又有各自的依赖的jar包，他们的版本搭配非常关键，例如springmvc4用的jackson框架是2.1， springmvc3 用的jackjson框架是1.x版本，你如果搭配错了，项目运行不起来了。再比如spring和mybatis, hibernate之间的无缝结合，虽然是互相搭配，但你如果用的版本不一致，也会造成项目出错。未来我们想升级某个框架，比如从spring4升级到spring5,也是不是单纯的只升级spring4, 而是要考虑hibernate, mybatis等框架的联动升级。

  所以采用Maven来提供工程的中央仓库，所有的子模块共享一个POM文件，避免各个子模块各自重复依赖一大堆jar包。Maven的多模块其实就是按照层级的管理构建，项目包含一个pom.xml文件和若干个模块，每个模块有一个单独的pom.xml文件，通过pom的依赖和继承关系来构建项目层次。一旦建好以后，就可以终身享用，工作量会大大降低，jar包版本不一致的造成的项目风险会大大降低。

  而整个项目工程的拷贝复制就更加简单，里面不再有大量的jar包，开发人员只需从配置库上更新最新的代码后，配置库中不再有大量的开源框架jar包，而是从Maven中央仓库中自动更新。建立工程的时候，直接选择导入Maven工程，一键将所有的模块导入到新的workspace当中，非常方便。

 购买GPS平台或GPS监控系统源码，联系我2379423771@qq.com

以下是在Myeclipse开发环境下的Maven工程截图

Maven的POM.xml文件配置：

以下是IntelliJ IDEA开发环境下的工程截图

jt808协议服务器开发环境

使用IDEA的Maven插件，结合源码工程的POM文件中的现成的编译脚本，开发人员不用在做额外的工作，直接点击install，就可以一键打包部署，非常方便。

Maven打包jt808项目可执行jar包

工程目录和包命名规范

我现在根据Spring的注释，包的命名，当然这首先建立在你对三层架构的熟悉上。

com.ltmonitor.jt808.app    808服务器应用程序

com.ltmonitor.jt809.app    808服务器应用程序

com.ltmonitor.web.vo       用于web页面传递的对象

com.ltmonitor.service.vo   用于服务传递的对象

com.ltmonitor.controller   MVC中的控制,Spring的注释@controller

com.ltmonitor.controller.map        地图表现层

com.ltmonitor.controller.terminalcommand 终端指令

com.ltmonitor.entity     实体类

com.ltmonitor.entity.jt808 专用于808gps服务器的实体类

com.ltmonitor.entity.jt809 专用于809服务器的实体类

com.ltmonitor.dao  Dao层

com.ltmonitor.servce service层

com.ltmonitor.server  gps服务器层

。。。

。。。。。

。。。。

完备的开发手册可以帮助开发者理解整个开发平台

部标监控平台开发手册

 

数据字典：

部标监控平台数据字典

 

主界面

 

部标808监控平台主界面

 

支持百度高德地图聚合

百度高德地图聚合

支持海量车辆在地图上的位置显示和移动，通过颜色区分车辆的在线状态和停车行驶状态

海量车辆GPS位置地图显示

 

海量车辆位置在百度地图上显示

支持车辆GPS状态和地图图标自定义：

车辆地图图标定义

(34186)

]]> http://www.jt808.com/?feed=rss2&p=939 0 jt/t 1077-2016标准 交通部部标平台道路运输车辆卫星定位系统视频监控平台要求 http://www.jt808.com/?p=573 http://www.jt808.com/?p=573#comments Tue, 28 Oct 2014 10:10:52 +0000 admin http://www.ltmonitor.com/blog/?p=573 道路运输车辆卫星定位系统视频监控平台jt/t 1077-2016标准

 

如需通过部标检测，参见文章：部标1077视频平台过检和压力测试经验分享

基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标视频监控平台

　1范围

本标准规定了道路运输车辆卫星定位实时音视频监控架构，以及道路运输车辆卫星定位实时音视频监控系统中政府监管平台和企业监控平台的功能要求、平台性能与技术要求等内容。

本标准适用于道路运输车辆卫星定位实时音视频监控系统政府平台及企业自建或运营商搭建的音视频监控系统平台。

　2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

JT/T 794-2011 道路运输车辆卫星定位系统 车载终端技术要求

JT/T 796-2011 道路运输车辆卫星定位系统 平台技术要求

JT/T 1078-2016 道路运输车辆卫星定位系统 视频通信协议

 

ISO/IEC standard 13818-1 MPEG-TS媒体格式标准（又称为 ITU-T Rec. H.222.0）

RFC 3261 会话初始协议

　3术语、定义和缩略语

JT/T 796界定的以及下列术语和定义适用于本文件。

.3.1　术语和定义

下列术语和定义适用于本文件。

.3.1.1　 

音视频终端

负责将音频和视频采集编码的硬件设备，一般为嵌入式产品。要满足工业环境要求，高稳定性。

.3.1.2　 

音视频流转发服务器

负责将终端上传的音视频流数据统一分发给监控客户端软件，减少因多个监控客户端同时访问同一终端音视频而导致数据重复编码、传输，将无线通信带宽占用降到最低要求。

 

.3.1.3　 

信令网关

平台之间互联的逻辑部件，负责接收外平台的信令。

 

.3.1.4　 

媒体网关

平台之间互联的逻辑部件，在信令网关的调度下，将本平台相关的视频传输到目标接收方。

 

.3.2　缩略语

下列缩略语适用于本文件。

 

AES：高级加密标准（Advanced Encryption Standard） 

B2BUA：背靠背用户代理（Back to Back User Agent） 

CIF:通用中间格式（Common Intermediate Format） 

DES：数据加密标准（Data Encryption Standard） 

DNS：域名系统（Domain Name System） 

IP：因特网协议（Internet Protocol） 

IPsec：因特网安全协议（Internet Protocol Security） 

MD5：信息摘要5（Message Digest Algorithm 5） 

NAT/FW：网络地址翻译/防火墙（Network Address Translator and FireWall） 

NTP：网络时间协议（Network Time Protocol） 

RTCP：实时传输控制协议（Real-time Transport Control Protocol） 

RTP：实时传输协议（Real-time Transport Protocol） 

RTSP：实时流化协议（Real-Time Streaming Protocol） 

SDP：会话描述协议（Session Description Protocol） 

SHA：安全哈希算法（Secure Hash Algorithm） 

SIP:会话初始协议(Session Initiation Protocol)

SVAC:安全防范监控数字视音频编码(Surveillance Video and Audio Coding) 

S/MIME:安全多用途网际邮件扩充协议(Secure Multipurpose Internet Mail Extensions) 

TCP:传输控制协议(Transmission Control Protocol) 

TLS:传输层安全(Transport Layer Security) 

UDP:用户数据报协议(User Datagram Protocol) 

XML:可扩展标记语言(EXtensible Markup Language)

URI:统一资源标识(Uniform Resource Identifier)

URL：统一资源定位(Uniform Resource Locator)

URN：统一资源命名(Uniform Resource Name)

　4道路运输车辆卫星定位实时音视频监控系统架构

 

 
 

 

 

道路运输车辆卫星定位系统视频监控平台具备JT/T 796的全部功能，完全兼容JT/T 808和JT/T 809通信协议，并在此基础上，提供车载实时音视频及录像监控功能。

道路运输车辆卫星定位系统视频监控平台在系统结构上分为两个层面：

ñ 政府监管平台

ñ 营运企业监控平台

政府监管平台分为三级，分别为：部级监管平台，省级监管平台，地市级监管平台。

政府监管平台之间通过专线网络或互联网VPN方式进行连接，企业监控平台与政府监控平台可以通过互联网专线网络方式进行连接。

政府监管平台之间可实现跨域的音视频资源目录信息访问，企业监控平台提供音视频资源目录的录入和管理以及实时音视频和录像点播功能。

车载终端与企业监控平台间通过无线通讯网络连接，数据传输采用JT/T 808协议传输卫星定位信息和音视频控制信令信息，采用RTP协议传输音视频数据。

　5政府监管平台功能

.5.1　音视频资源目录管理

.5.1.1　目录结构

（针对上次会议讨论中采用文件目录结构定义音视频资源目录的做法，这里应摒弃，以“\”分割目录结构是Windows下文件结构组织方式（Linux和Unix以“/”作为文件目录分隔符），而本标准是建立更为统一、更为通用的目录标识，因为具体的音视频资源可能以文件方式存储于Windows平台、Linux或Unix平台，还可能以某种网络资源方式存在某些HTTP/FTP/NAS/SAN等网络服务器上。所以音视频资源的标识应同具体存储方式分离，不能简单的定义成Windows文件目录形式，建议采纳国际标准 RFC3986的URI方式定义音视频资源标识，具体以国际标准的ldap schema为基础）

(此部分原内容删除：音视频资源目录在音视频数据文件物理存储结构之上，将音视频数据文件信息重新组织为五级目录的结构，平台以音视频资源目录的形式，作为对音视频数据进行访问及管理的统一界面。

音视频资源目录的路径以“\”作为根目录；第一级目录根目录；第二级、第三级目录行政区划省和地市名称为依据，；第四级目录为企业监控平台名称；第五级目录为车牌号码；车辆的音视频数据文件信息包含在对应的第五级车牌号码目录中。

考虑增加运输企业这一等级？

第五级车牌号码目录中的每条音视频资源目录项包含在当前目录下唯一的目录项名称和属性，每条音视频资源目录项对应一个音视频资源。音视频数据文件信息的属性参见附录A。）

本标准不限制音视频资源数据的物理存储方式，只对音视频资源目录信息定位要求符合以下规范：

音视频资源目录信息内含两类信息：

ñ 目录结构标识

ñ 目录节点数据

5.1.1.1 目录结构标识（Directory URI)

根据交通行业的实际情况，其标识分为4级层次：

1) 部

2) 省

3) 地市

4) 企业

具体标识结构为：

ldap://moc/省/地市/企业

其中 “moc”默认表示“交通运输部”。

 

5.1.1.2 目录节点数据（Directory Entry Attribute)

目录节点用于记录音视频资源各项属性，参见附录A和附录B

 

 

附录A 音视频资源目录标识说明

序号

标识名称

标识结构

说明

 

平台标识

ldap://moc/省/地市/企业

如：
ldap://moc/北京市/北京市/北京市企业监控平A，

表示北京市某企业监控平台

 

平台链接配置

ldap://moc/省/地市/企业/access

如：
 ldap://moc/北京市/北京市/北京市企业监控平A/access，此目录有两个属性：

server_ip:平台IP地址或域名

server_port：平台端口号

 

车辆标识

ldap://moc/省/地市/企业/vehicle_color/vehicle_license

如：

ldap://moc/北京市/北京市/北京市企业监控平A/蓝/京A12345

 

附录B 音视频资源目录属性细节说明

序号

标识名称

标识结构

说明

 

开始时间

日期时间

音视频数据的开始采集时间，如：2012-5-1 18:00:00

 

结束时间

日期时间

音视频数据的结束采集时间，如：2012-5-1 18:00:00

 

数据文件大小

数值

音视频数据的字节大小

 

数据文件长度

时间长度

音视频数据从采集开始到采集结束时间长度，如：00:15:00

 

开始位置

经纬度数据组

音视频数据的开始采集位置，如E113.123456,N23.123456

 

结束位置

经纬度数据组

音视频数据的结束采集位置，如E113.123456,N23.123456

 

数据采集设备编号

数值

音视频数据采集设备的编号，每个车辆均从1开始编号

 

数据采集设备类型编号

数值

参见附表1.1 数据采集设备类型编号表

 

数据采集设备中文名称

字符串

一般用于描述数据采集设备的安装位置

 

音视频数据内容类型编号

数值

参见附表1.2 音视频数据内容类型编号表

 

报警状态

数值

报警状态编码

 

备注

字符串

对音视频数据的备注说明

 

音视频数据时效标志

数值

表示音视频数据是实时数据还是历史数据

 

音视频数据格式类型编号

数值

4位数值，前2位数值为视频数据格式类型编号，
后2位数值为音频数据格式类型编号

 

音视频数据地址描述

字符串

在平台中可唯一标识并取得音视频数据文件内容的字符串

 

经营许可证号

字符串

　车辆经营许可证号

 

 

 

 

.5.1.2　目录管理

对音视频资源目录的管理包含自动更新、资源信息查询与统计、接受订阅功能。具体要求如下：

a）平台根目录根据平台类型自动进行初始化；

（如北京市某企业监控平台的根目录自动初始化为：ldap://moc/北京市/北京市/北京某企业监控平台，起草阶段示意用）

b)自动更新，政府监管平台本身不产生音视频资源目录项，平台能够将下级平台和外部平台上传的音视频资源目录进行自动融合与更新；（政府监管平台部分描述）

b)自动更新，音视频资源目录由平台根据音视频数据文件的变化进行自动更新；（企业监管平台部分描述）

c) 音视频数据文件查询，可通过音视频数据文件信息属性进行条件组合查询；

d) 音视频数据文件统计，可通过音视频数据文件信息属性对音视频数据信息文件的数量、大小、时长进行统计；

e) 音视频资源目录自动上传，音视频资源目录变化后，平台主动向上级平台更新音视频资源目录，具有增量更新和全量更新功能；

f) 通过授权验证后，音视频资源目录可被外部平台订阅，订阅后平台自动向订阅音视频资源目录的目标平台自动更新音视频资源目录；

 

.5.2　用户管理

.5.2.1　用户设置

 

平台用户应具备管理员、普通用户二种用户类型：

a) 客户管理员：具有使用监控客户端，负责本单位系统管理、设备管理以及本单位用户管理与权限分配的用户

b) 用户：具有使用使用监控客户端，按客户管理员分配的权限进行系统操作的用户

 

用户模型支持用户，角色，权限的模型，也可以直接对用户赋予单个设备的权限，具体要求如下：

a) 一个用户可以有多个角色

b) 一个角色多个权限 

c) 一个用户可以直接有多个权限

 

每个用户都依据音视频资源目录具备一定的级别，在多个用户抢占资源的时候，依据高优先级资源使用权高的策略来对资源进行处理

 

平台支持用户的增加，删除，修改。多个角色管理、用户级别定义的功能。

 

.5.2.2　权限管理

 

权限按照功能分为设备功能权限和用户权限等级

功能权限包括：实时视频浏览权限，历史视频浏览权限，云台控制权限，视频参数设置权限

用户级别主要设置了当前访问用户访问的优先级

 

用户权限可以被赋予，也可以被收回。系统根据用户的不同身份，给予不同的操作权限。管理员可对所辖平台进行业务管理、业务汇总统计。管理员可对本系统进行一切操作。

系统的用户可归入用户组，然后集中被赋权，亦可对用户单独赋权。另外，云镜控制等占有型或夺权型操作的权限，需要按照用户权限等级来决定控制策略。

 

权限按照授予方式的不同分为跨域权限、非跨域权限、平台内权限

跨域权限：归属地车辆进入跨域地，跨域地平台自动给归属地授权，授权地就是跨域地

非跨域权限：用户请求一个跨域地的资源（当前资源属于跨余地），授权地发生在用户所在域和跨域地的共同的上级

 

.5.2.3　用户分级机制

系统要求采用分级用户管理机制，根据用户的不同身份，给予不同的权限级别，主要用来在资源发生争用的情况下，依据用户权限级别做相应的策略，系统应具备：

a) 通信链路达到满的时候给用户提示

b) 高优先级别的用户可以抢占低优先级别用户占用的通信资源

 

.5.2.4　用户可见资源目录

用户登陆，依据用户权限，获得用户可见的资源目录，并且在可见资源目录上进行二次检索，系统应具备：

a) 按机构层次来进行展示设备浏览，不同类型的设备要显示为不同类型的图标

b) 具备用户常用设备分组能力

c) 具备模糊匹配快速定位设备能力

 

.5.2.5　用户日志管理

日志管理部分主要用来做用户日志审计，包括：

a) 支持查询一个用户，一个时间段在做什么操作

b) 支持查询一个设备，在一个时间段，那些人进行操作

c) 支持统计出，当前那些人操作比较频繁

d) 支持对实时和历史音视频调阅行为作记录，包括时间段、发起方用户身份、目标音视频数据归属企业、流量，并可生成查询报表，支持报表的excel导出功能。

 

 

.5.3　视频监控

 

.5.3.1　实时浏览

支持在远程计算机上或者移动终端通过浏览器或者相应的客户端软件对终端的实时监控视频进行浏览（此处考虑有可能支持手机端或平板电脑的音视频监控能力，并且用“浏览器”替代“IE”，更为通用）。浏览客户端可采用B/S或C/S架构。视频监控界面应支持1、4、9、16等画面的分割显示，在同一界面上支持显示同一终端的多路图像，同时支持显示不同终端的不同图像，并支持实现视频图像的全屏幕显示。应包括调阅路径、视频调节、实时抓图、音频监听、电视墙等功能

——调阅路径：通过树状组织结构、电子地图、车牌号搜索等多种方式快速调阅查看。

——视频调节：对实时浏览的图像进行亮度、色度、对比度、饱和度的调节。

——实时抓图：对正在浏览的视频图像进行抓图，并对所抓图片进行描述、保存，及日后查询。

——音频监听：实时浏览图像的同时，打开/关闭实时音频的监听。

——电视墙展示：可支持通过硬解码或者软解码的方式将实时视频输送到电视墙上显示。

.5.3.2　定位、视频同步显示

车辆的实时卫星定位情况和视频支持在同一监控界面同时、同步显示。

.5.3.3　云镜控制（企业）

云镜控制应包括云台控制和镜头远程控制功能。

——云台控制：具备云台的上下左右转动，预置位设置、自动巡航等，并支持雨刷、辅助灯光开关功能。

——镜头控制：具备镜头变倍、镜头变焦、光圈调整功能。

 

.5.4　录像功能

.5.4.1　录像存储

支持客户端手动录像和中心存储录像功能，并能将录像存储

.5.4.1.1　客户端手动录像

支持浏览视频时将视频实时存储在客户端本地硬盘。

.5.4.1.2　中心存储录像

支持定时录像、手动录像和报警录像三种模式。并具备海量存储功能，支持设置用户存储空间满自动覆盖或停止录制。

——定时录像具备系统中用户预先设置的时间计划进行录像。

——手动录像具备用户手动设置开始录像、停止录像以及设置录像时长等功能进行控制录像。

——报警录像具备通过IO报警触发、视频移动侦测触发等报警事件发生而触发的录像。

.5.4.2　录像检索、回放、下载

客户端支持终端及中心存储服务器或视频复用服务器的录像文件进行检索、回放、下载；

——录像检索具备提供快捷的录像检索方式，支持按视频通道、时间、报警类型等信息进行快速检索。

——录像回放具备实现播放、快放、慢放、单帧放、拖曳、暂停等功能；至少支持实现2路的图像同步回放及全屏回放。

——录像下载具备支持录像文件按文件、按时段下载，可支持多个文件一次性下载。

随机主码流历史视频数据下载

 

.5.5　视频复用

5.4.1政府监管平台具有（实时视频）存储和转发的功能；视频数据获取于企业监控平台，以便于政府监管用户复用。

5.4.2  流媒体转发示意

 

        车载监控主机————企业管理平台—————政府监管平台

 

                                 ︱                     ︱

 

                              企业用户               政府管理用户

 

5.4.3政府平台应具备对管辖区域内的历史音视频调阅请求回应目标终端所在的企业平台服务器的地址、端口和身份校验信息，用于请求方建立历史音视频通道。

 

政府平台应对跨管辖区域的历史音视频调阅请求向上级平台转发，接收响应并回传给请求方，用于请求方建立历史音视频通道。政府平台不负责为企业用户对历史音视频数据的转发。

 

5.4.4 可通过企业监控平台或政府监管平台，对已在服务器上保留的视频进行在线回放。

 

5.4.5企业平台对子码流录像数据的存储不得少于10天，复用视频数据的总量不少于XX小时。

 

.5.6　对外接口

 

.5.6.1　与上级政府平台接口

政府平台应该具备应具备与上级政府平台之间的信息交换功能，包括摄像机点位信息，实时视频图像调阅。具体参考平台间互联接口

具备对同级别其他政府部分视频自愿访问权限的功能。

 

　6企业监控平台功能

 

(此图建议删除，在以下内容中对企业音视频监控平台的功能已作了条目化的要求和说明，符合标准的常见阐述方式，这张图类似具体产品的功能结构和层次设计，过于具体，约束了各产商在实现平台功能时设计思路，而且涉及到了JT/T 796中已定义过的核心内容，容易引起两个标准的冲突）

.6.1　音视频资源目录管理

 

.6.2　用户管理

.6.2.1　用户管理

支持用户的增加，删除，修改。

用户分为管理员和普通用户二种：

l 客户管理员：使用监控客户端，负责本单位系统管理、设备管理以及本单位用户管理与权限分配；

l 用户：使用监控客户端，按客户管理员分配的权限进行系统操作。

l 上级政府用户

l 其他政府用户

 

用户模型应该满足用户，角色，权限的模型，也可以直接对用户赋予单个设备的权限，具体要求如下：

d) 一个用户可以有多个角色

e) 一个角色多个权限

f) 一个用户可以直接有多个权限

 

.6.2.2　权限管理

用户权限可以被赋予，也可以被收回。系统要求采用分级用户管理机制，根据用户的不同身份，给予不同的操作权限。管理员可对所辖平台进行业务管理、业务汇总统计。管理员可对本系统进行一切操作。

系统的用户可归入用户组，然后集中被赋权，亦可对用户单独赋权。权限分为系统管理、视频浏览、云镜控制、报警管理、录像管理和用户管理几种。设备也可被编入设备组或单独赋权。另外，云镜控制等占有型或夺权型操作的权限，需要按照用户权限等级来决定控制策略。

 

归属地

跨域地

授权地

.6.2.3　日志管理

日志管理部分主要用来做用户日志审计，包括：

l 可以查询到一个用户，一个时间段在做什么操作

l 可以查询到一个设备，在一个时间段，那些人进行操作

l 可以统计出，当前那些人操作比较频繁

l 可以对实时和历史音视频调阅行为作记录，包括时间段、发起方用户身份、目标音视频数据归属企业、流量，并可生成查询报表，支持报表的excel导出功能。

.6.2.4　设备管理

设备管理主要包括对平台设备、前端设备、前端外围设备的入网、管理功能。

l 设备入网

系统中需要增加的设备主要包括平台设备、前端设备及前端外围设备。前端设备包括有各种型号的视频服务器、网络摄像机、DVR 等，外围设备摄像机又包括模拟摄像机、云台及报警设备等。

 

l 配置设备属性

平台设备的属性包括设备的种类、型号、生产厂家、安装地点、接入线路方式、所属用户、使用状态等。设备都有一个唯一的设备ID作为标识。

外围设备摄像机的属性包括摄像机的种类、型号、生产厂家、安装地点、接入线路方式、所属用户、使用状态等。

前端设备视频服务器属性包括型号、生产厂家、安装地点、接入线路方式、所属用户、使用状态及相连的摄像机等。视频服务器有一个唯一的设备ID 作为标识。

 

l 设备注销

各设备在停止使用时可以进行注销，设备的注销对其关联的设备或系统会产生影响的应给予提示。

 

l 统计与查询设备

可以按照设备的各项属性进行设备统计与查询操作，例如设备在线统计。

 

l 启/停用设备

在某个设备需要暂时停止使用时（如发生欠费行为等），系统具有暂时停用该设备的功能，同时具有启用功能，以在条件达到时恢复该设备的使用。

 

 

.6.3　视频监控

.6.3.1　实时浏览

要求可以在远程计算机或移动终端上实时监控，亦可实现在远程通过硬件解码器在监视器、电视墙上观看实时视频。浏览客户端可采用B/S或C/S架构。可实现对电视墙投放视频的灵活控制。具体还应包括以下功能：

a) 多画面监视

PC浏览客户端上要求可以实现对多个监控点的显示，电视墙上要求可实现将指定的一个或多个监控点实时图像显示在指定的一个或多个显示器上，可以选择1，4，6，9，10，16等多种画面分割，能提供多种分辨率，以适应各种应用需求，并可以实现全屏显示。 

b) 多画面轮巡 

可将一组图像设置在一个播放控件窗口或一个电视墙屏幕上，并可设置轮巡间隔时间，以实现多个画面轮流显示。

c) 设置功能

要求实现图像参数的手动和自动设置并实时调整的功能。

d) 字幕叠加

视频画面要求可叠加反映该段视频时间、地点等信息的字幕，选择实现字母位置可调。

e) 视频调节

可调节视频画面的亮度、色度、对比度、饱和度、尺寸，以及音频的大小、开关。

 

.6.3.2　定位视频同步显示

根据

.6.3.3　云镜控制

要求系统支持对云台和镜头的远程实时控制。

云台控制为云台的上下左右转动，支持各种自动控制功能：

l 巡航功能

l 预置位

l 支持雨刮、辅助灯光开关功能。

云台转动的步进值应可设置。

镜头的控制应包括：

l 变倍：图像放大缩小

l 调焦：应具有手动和自动调焦功能

l 光圈：应具有手动和自动光圈调节功能

要求客户端在全屏显示状态下亦可进行云镜控制。

云镜控制权限可设置为2种状态：

l 先来者占用模式。系统可设置一个用户开始控制云台后的指定时间之前内，云台归该用户占用。直到时间片用尽才为后来的用户提供服务。

l 权高者占用模式。系统根据用户的权限决定执行哪位用户的命令。同级之间可遵循先来者占用原则，权限高的用户开始控制时，则将控制权转移。用户可以锁定云镜控制，同时设置锁定超时时间。高权限用户锁定后，低权限用户不能解锁，待超时后系统自动解锁。

 

 

.6.4　录像功能

.6.4.1　实时录像

企业平台应对本企业内的历史视频调阅请求回应，建立通信通道，向调用方回传历史音视频流数据。

系统要求支持三级视频存储：前端存储、中心存储和客户端存储。

前端存储是指使用音视频终端设备时，在前端设备内部的硬盘中进行录像。应可设置盘满自动覆盖或停止录制。支持定时录制、手动录制和报警录制三种模式。

中心存储是指平台所提供的海量存储功能。应可设置用户存储空间满自动覆盖或停止录制。支持定时录制、手动录制和报警录制三种模式。

客户端存储是指客户在浏览视频时将视频的实时存储在客户端本地硬盘的功能。支持手动录制和报警录制两种模式。

三种录制模式的解释如下：

定时录制：根据系统中用户预置的时间表进行录像。

手动录制：按照用户的开始录像、录像时长、停止录像指令进行控制的录像。

报警录制：由系统中事件（报警触发、图像运动检测触发）的发生而触发的录像，报警录制应该有预录功能，可设置对报警发生前多少时间的视频信息进行录制。并且应可设置一次报警发生后总的录像时长。

 

.6.4.2　录像下载

可以提供方便的录像检索、查询手段，可根据时间、地点和报警类型等信息检索并回放图像。

应可实现录像的按文件、按时段下载功能。

 

.6.4.3　录像回放

回放时可实现播放、快放、慢放、单帧放、拖曳、暂停等功能，可选择实现多路图像同步回放功能。回放用户交互界面要求尽可能友好，可以直观地为用户反映所查日期一个的录像资料情况，并可以点取播放。用户选择观看的视频为正在录制的文件时可以选择实现为用户打包然后播放。

要求提供录像文件播放器

录像回放需要支持VOD方式和FTP方式

 

 

.6.5　报警（终端）

企业平台应能通过设定报警条件，触发终端主动上传报警音视频流数据。包括：

1) 视频丢失

2) 图像运动检测：要求系统支持图像运动检测报警。须实现指定画面中区域进行运动检测报警的功能。并可设置运动检测灵敏度。选择实现画面多区域运动检测报警。

3) 视频设备故障

设备完好情况统计

.6.5.1　视频报警管理

中心平台在收到报警信息后，根据用户配置的报警联动表信息进行联动处理。主要操作包括触发报警录像及图片抓拍、发送报警短信给用户、向用户电话提供语音报警等。同时需要将报警信息传送到该客户正在进行监控操作的用户处，并且传送给指定的专用报警客户端处。

 

.6.6　视频复用

6.6.1企业平台应具有视频（实时视频）存储和转发的功能；在任意用户调用车载视频时，企业平台将调用视频存储与平台数据库，便于后期复用

 

　7平台互联接口

.7.1　政府视频平台间互联接口

.7.1.1　下级政府监管平台向上级政府监管平台请求登陆和主链路保持

参考809中4.3.1.1

.7.1.2　平台间信息交互业务流程

.7.1.2.1　音视频目录资源上报

下级平台登陆完上级平台后，需要将自己管辖下的相关音视频资源目录主动上报到上级平台，应遵循以下规定：

a) 下级平台登陆完成后，按照音视频资源目录将对应资源上报到上级平台

b) 下级平台应将自己平台下属所有的目录资源信息上报

 

.7.1.2.2　音视频目录资源查询

下级平台应具备相应上级平台查询音视频目录的请求，上级平台可以查询下级平台任意节点的音视频资源目录

 

.7.1.2.3　报警上报流程

参考809中4.3.5

.7.1.3　平台间视频业务流程

.7.1.3.1　上级政府监管平台查看下级政府监管平台实时视频

上级政府监管平台查看下级政府监管平台实时视频，实现流程应遵循如下规则：

a) 上级政府监管平台请求视频到下级政府监管平台，携带访问的用户信息是上级平台用户信息, 请求视频资源名称

b) 如果下级政府监管平台中已经存在查看的视频源存在，直接返回上级平台，否者执行c

c) 下级政府监管平台将对应的请求转发到下一级平台

a) 如果下一级平是企业监控平台，流程参考7.2.4

b) 如果下一级别是政府监管平台，重复执行b、c 

 

.7.1.3.2　上级平台响应外平台视频查看下级政府监管平台实时视频

基本同7.1.4，只是携带的用户信息是外平台访问用户

 

.7.1.3.3　上级政府监管平台控制视频资源云台

上级政府监管平台控制视频资源云台，实现流程应遵循如下规则：

a) 上级政府监管平台控制云台到下级政府监管平台，携带访问的用户信息是上级平台用户信息, 请求视频资源名称，用户级别

b) 如果下级政府监管平台中已经存在有高优先级用户控制，返回不可控，否者执行c

c) 发送指令到下级平台，重复执行b,c

 

.7.1.3.4　上级政府监管平台设置视频源视频质量

上级政府监管平台设置视频源视频质量，实现流程应遵循如下规则：

a) 上级政府监管平台控制云台到下级政府监管平台，携带访问的用户信息是上级平台用户信息, 请求视频资源名称，用户级别

b) 如果有下级政府监管平台，发送指令到下级平台，重复执行

 

.7.1.3.5　上级政府监管平台查看下级政府监管平台历史视频

.7.1.3.5.1　视频检索

上级政府监管平台查看下级政府监管平台历史视频，实现流程应遵循如下规则：

c) 上级政府监管平台请求视频到下级政府监管平台，携带访问的用户信息是上级平台用户信息和时间信息，请求设备唯一标识

d) 如果下级政府监管平台中已经存在查看的视频记录存在，直接返回上级平台视频资源记录，否者执行c

e) 下级政府监管平台将对应的请求转发到下一级平台

a) 如果下一级平是企业监控平台，流程参考7.2.4

b) 如果下一级别是政府监管平台，重复执行b、c

f) 返回的视频资源记录列表中包含视频可以唯一标识的URI 

 

.7.1.3.5.2　视频回放

上级政府监管平台查看下级政府监管平台历史视频，实现流程应遵循如下规则：

a) 上级政府监管平台请求视频到下级政府监管平台，携带访问的用户信息是上级平台用户信息和时间信息，请求视频资源唯一标识

b) 如果下级政府监管平台中已经存在查看的视频记录存在，直接返回上级平台，否者执行c

c) 下级政府监管平台将对应的请求转发到下一级平台

a) 如果下一级平是企业监控平台，流程参考7.2.4

b) 如果下一级别是政府监管平台，重复执行b、c

d) 按照访问路径的反方向一级一级的将对应的视频传递到发起请求方的上级政府监管平台

 

.7.1.3.6　上级平台响应外平台视频查看下级政府监管平台历史视频

基本同7.1.6，只是携带的用户信息是外平台访问用户

 

.7.2　企业视频平台和政府视频平台间接口

.7.2.1　下级平台向上就平台请求登陆和主链路保持

参考809中4.3.1.1

.7.2.2　平台间信息交互业务流程

同7.1.2

.7.2.3　平台间视频业务流程

.7.2.3.1　上级政府监管平台查看企业监控平台实时视频

上级政府监管平台查看企业监管平台实时视频，实现流程应遵循如下规则：

a) 上级政府监管平台请求视频到企业监控平台，携带访问的用户信息是上级平台用户信息, 请求视频资源名称

b) 如果企业监控平台中已经存在查看的视频源存在，直接返回上级平台，否者执行c

c) 企业监控平台向车载终端发起查看实时视频请求

d) 车载终端将视频发送到企业监控平台

e) 企业监控平台将对应的视频发送到上级政府监管平台

 

.7.2.3.2　上级政府监管平台控制视频资源云台

上级政府监管平台控制视频资源云台，实现流程应遵循如下规则：

a) 上级政府监管平台控制云台到企业监控平台，携带访问的用户信息是上级平台用户信息, 请求视频资源名称，用户级别

b) 如果企业监控平台已经存在有高优先级用户控制，返回不可控，否者执行c

c) 发送指令到车载终端

 

.7.2.3.3　上级政府监管平台设置视频源视频质量

上级政府监管平台设置视频源视频质量，实现流程应遵循如下规则：

a) 上级政府监管平台控制云台到下级政府监管平台，携带访问的用户信息是上级平台用户信息, 请求视频资源名称，用户级别

b) 发送指令到车载终端

 

 

.7.2.3.4　上级政府监管平台查看企业监控平台历史视频

.7.2.3.4.1　视频检索

上级政府监管平台查看下级政府监管平台历史视频，实现流程应遵循如下规则：

a) 上级政府监管平台请求历史视频到下级政府监管平台，携带访问的用户信息是上级平台用户信息, 请求设备唯一标识

b) 如果企业监控平台中已经存在查看的历史视频源存在，直接返回上级平台视频资源目录，否者执行c

c) 企业监控平台向车载前端发起历史视频检索请求

d) 车载终端将历史视频列表发送到企业监控平台

e) 企业监控平台将对应的历史视频列表发送到上级政府监管平台

f) 返回的视频资源记录列表中包含视频可以唯一标识的URI 

 

 

.7.2.3.4.2　视频回放

上级政府监管平台查看企业监控平台历史视频，实现流程应遵循如下规则：

g) 上级政府监管平台请求视频到企业监控平台，携带访问的用户信息是上级平台用户信息, 请求视频资源URI

h) 如果企业监控平台中已经存在查看的历史视频源存在，直接返回上级平台历史视频，否者执行c

i) 企业监控平台向车载前端发起历史视频查看请求

j) 车载终端将历史视频发送到企业监控平台

k) 企业监控平台将对应的历史视频发送到上级政府监管平台

 

 

　8性能与技术指标

.8.1　平台总体性能

平台总体性能应至少满足以下要求：

a) 支持平台7×24h不间断运行；

b) 在没有外部因素影响的情况下，故障恢复时间不超过120min。

.8.2　系统音视频终端接入性能

平台音视频终端接入性能应满足以下要求：

a) 具有海量音视频数据高并发处理能力：平均≥500Mbps、峰值≥1000Mbps；

b) 企业平台能支持至少3000台音视频终端接入，支持超过10000个视频摄像头的监控能力；

c) 政府平台（县级除外）能支持至少30000台音视频终端接入，支持超过100000个视频摄像头的监控能力；

d) 音视频实时监控平均延迟时间≤10s

e) 单个音视频实时监控多通道同步时间差异≤5s；

f) 音视频监控平均响应时间≤10s。

.8.3　平台响应时间

最大并发用户达到其系统设计要求时，各事务平均响应时间不应超过单用户平均响应时间的五倍。

.8.4　音视频质量

音视频实时监控数据分辨率至少为QVGA（320×240）,平均帧率≥12FPS，音频流采样率≥16kHz；

音视频记录回放数据分辨率至少为4CIF（704×576）, 平均帧率≥12FPS，音频流采样率≥16kHz；

.8.5　地图数据质量

地图数据质量应符合JT/T 796-2011中的要求。

.8.6　网络传输

网络传输环境应满足以下要求：

a) 政府平台之间支持专线网络或互联网VPN连接；

b) 企业平台支持互联网或专线网络等方式连接政府平台。

.8.7　数据存储和备份

数据存储和备份要求如下：

a) 音视频数据在线存储时间不得少于30天；

b) 报警音视频数据在线存储时间不得少于60天；

c) 建立数据备份机制，每月对数据进行全量备份，每周对数据进行增量备份，系统数据恢复时间不超过5h。

　9安全要求

引用796中要求

(12806)

]]> http://www.jt808.com/?feed=rss2&p=573 0