部标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平台数据交换及转发服务器

(6284)