谁念西风独自凉

MediaServer流媒体服务器，是为满足JT/T 1078道路运输车辆卫星定位系统视频通信协议、GB/T 28181公共安全视频监控联网系统的国家标准,开发的流媒体服务器，用于接入终端的实时音视频流，并转换为可在Web页面或播放器播放的流媒体数据，供客户端调用及音视频播放。同时满足RTSP、RTMP等裸码流推拉流支持。

上一篇介绍了，这里说一下如何对接主动安全附件服务器。流媒体的对接主要牵扯到4个方面：（1）平台端：业务端系统，包含前端呈现界面。（2）JT/T808网关：部标设备接入网关，这个是非常重要的，是设备与平台进行数据交换的桥梁，流媒体相关的指令操作也必须依赖它完成。（3）部标视频机：符合JT/T808协议的车载视频机器。（4）流媒体服务：符合苏标、粤标、川标、陕标协议的主动安全附件服务，接收文件流，并存储。

对接过程中有很多的坑，特别是双向对讲，如果采集音频并通过流媒体抓发给设备，还有设备使用的那种编码格式，如何兼容海思头等等，如有兴趣的朋友可以一起交流沟通。

如下图是以实时视频点播与部标机产生了主动安全报警，各个服务之间的交互流程说明。整个系统有以下几个核心组件组成：1：系统业务端：车载监控业务系统，给用户提供车载监控整套业务流程与界面呈现；2：JT/T808网关：用来接入部标设备，通过TCP通讯在服务器与设备之间建立长连接进行实时数据交互，比如部标设备的定位数据、报警数据都是通过此应用上传到系统；

JT/T808消息体转义前言C#实现C#转义实现C#反转义实现Java实现JAVA 转义实现JAVA 反转义实现前言在网络传输过程中会存在粘包、半包等问题，在各个厂家做物联网产品的时候，大多会定义一种协议，协议里面包含了数据的包头、包尾以及校验位等字节，主要目的是为了在我们做物联网服务网关（接收物联网设备传输数据的系统）的时候方便对接收的数据进行校验以及处理粘包与半包问题。为了防止消息体里面出现与包头包尾相同的字节出现，在物联网设备进行组包的时候一般会进行转移，就是将消息体中出现与包头包尾相同的字节按

JT/T808组包的最重要一个环节之一就是对整个包（除去包头包尾的0x7E）内容按字节异或求和。C# 实现 public int getXorCode(byte[] data) { byte CheckCode = 0; int len = data.Length; for (int i = 0; i < len; i++) { Che

1.前言最近在思考如何利用智能终端采集的车辆信息，对车辆使用指标与司机驾驶指标进行数据挖掘，给出有价值的信息以供企业对司机进行评定。评定指标可能有多种，比如司机驾驶时长，运行公里数，油耗，以及产生的报警次数。结合这些指标，并对指标进行分类，并利用计算机的强大算力，并以一种最直观的方式展示给客户，这个驾驶员评定功能算具雏形。2.实施2.1.驾驶指标分类我这边考虑到不同的公司可能对指标分类标准不同，并且平台是基于SaaS，所以动态配置才更加符合当下要求。例如：根据百公里产生的特定报警

一、前言应国企客户要求，针对产品上行到平台的数据以及对平台下行到设备的数据进行国密SM4进行加解密，对此进行了SM4加密的理解与封装二、踩坑坑一：密钥大于16个字节当秘钥长度超过16字符(即128位)时会加密失败，报“java.security.InvalidKeyException: Illegal key size or default parameters”的异常这是因为美国对出口软件的控制，如果想移除这个限制需要修改Java环境！而且每个Java环境对这个限制修改还可能不一样！

一、项目介绍1.项目背景MediaServer流媒体服务器，是为满足JT/T 1078道路运输车辆卫星定位系统视频通信协议开发的流媒体服务器，用于接入终端的实时音视频流，并转换为可在Web页面或播放器播放的流媒体数据，供客户端调用及音视频播放。该项目终端接入部分采用高性能、基于Libuv框架实现，H264及音视频裸流到FLV，RTSP，RTMP的转换2.项目当前进展当前的流媒体服务器，支持满足1078协议的终端音视频接入，GB28181流接入。其中，视频流支持H264格式，音频流支持G7

最近喜欢上了做协议解析，最近使用Java与.NET做了很多的厂家的产品的协议网关。从部标系列到第三方私有协议，通过协议解析过程中了解每款产品的特色与将来可能的应用场景。下面我以一款第三方私有协议为例，利用C#语言进行优雅的做协议解析。原始数据：2475201509260111002313101503464722331560113555309F00000000002D0500CB206800F064109326381A03 序号 名称 值(HEX)

优化内容：1，优化视频处理逻辑，解决某部分设备因某一时刻发送大量数据包导致程序崩溃问题2，扩展程序功能，原始仅支持http-flv访问方式，当前版本支持rtsp/rtmp/http-flv/ws-flv三种访问方式，满足不同客户端播放需求3，更新系统底层架构，采用libuv作为驱动库4，支持H.264流设备直接接入5，支持实时视频录制功能(开放视频录制与结束录制接口，并且支持在线下载录制的视频)6，支持设备码流切换，可实时改变实时视频流的清晰度7，支持监测客户端拉流情况，无人拉流可以主动断.

前言：在19年底，和几个行业内的朋友就如何打造一款高可靠，易扩展，支持集群与分布式部署的部标平台进行了讨论。就在近期，我们规划的平台终于有了一个雏形。从网关到流媒体，到细分业务拓展，再到轨迹数据挖掘与业务分析。集大家这么多年以来的行业经验，以及对一些细分领域业务的理解，结合终端客户在使用平台过程中遇到的问题与操作体验方面整体进行了规划设计。网关：网关...

1.测试环境测试过程中，网关服务器是基于4核8G，5M外网宽带的Linux服务器，Netty网关单点运行的情况下进行的。 硬件信息表 硬件名称 规格 用途 阿里云服务器 4核8G 5M带宽 Netty网关+Redis+RabbitMQ+测试Web（单点） ...

之前说过基于1078的视频监控平台，下面我们聊聊基于苏标Adas协议的主动安全平台。苏标协议是对部标808协议的一种拓展，如果我们需要搭建苏标Adas主动安全平台，必须要先了解部标808的协议。了解过苏标协议的肯定明白，苏标是有个附件服务器的概念，其实这个附件服务器就是一个808的网关，然后根据苏标协议进行解析得到对应的报警图片，报警视频以及其他报警信息。这个就是1078视频监控的实现效果...

前言交通部与2016年10月份推出了JT/T 1078-2016标准，全称是《道路运输车辆卫星定位系统视频通信协议》。该标准将改变以往两客一危车辆的视频监控设备通信协议都是设备厂商私有协议的局面。JT/T 1078协议又是对JT/T808协议的拓展，在808协议的基础上增加了对视频设备通信协议的拓展。所以如果我们之前做过808的部标协议，再着手做1078协议就会容易理解很多。2018年...