前言

2019年的上半年开始做1078的音视频开发工作，并开源了jtt1078-video-server这个项目，在9月份创建了QQ群，认识了很多这个行业的开发人员，服务器端开发的、车载终端开发的，认识到了很多有趣的人，也大大的开拓了我在音视频方面的知识面。

JT/1078协议是用于营运车辆车载终端做音视频传输的一个协议，交通部对于很多车辆是要求强制安装的，并且实时的音视频传输协议必须是JT/1078协议，而这个协议起草得相当的差劲，文档里好几处错误、设计有缺陷、厂家不按套路来，并且在音视频传输的细节里，有很多不明确不详细的地方，对于初次接触音视频开发的人来说，无从下手、完全摸不着头脑是很正常的事，开发进度一拖再拖，领导给的脸色也是越来越差，真是太蛋疼了。。。

闲话不多说，JT/1078协议是对808协议的扩展，就是在它的基础上，增加了几个用于音视频传输控制的指令，以及几个报警信息，所以如果之前就已经有808协议服务器的，直接在它的基础上，增加1078协议的几个指令的传输控制就可以了。

角色

在整个音视频的传输与播放的环节里，是以下几个方面配合一起完成的。

1. 用户前端，比如浏览器网页或是手机APP。
2. WEB服务器，比如后端的J2EE WEB项目，承接用户端的操作，并与1078指令服务器打交道，是一个中间桥梁。
3. 1078指令服务器，在808的基础上，增加了对1078协议指令支撑的服务器端。
4. 流媒体服务器，当车载终端传输音视频数据上来时，需要完成对协议的解析，以及流媒体的转播等。
5. 车载终端，安装在车辆上，连接到我们的1078指令服务器上来，将车辆的一些实时数据传输到服务器端，并且能够响应服务器的下行指令。

一般流程

1. 用户前端选择车辆、以及要调阅的视频通道，向后端的WEB服务器发起调阅请求。
2. WEB服务器通知1078指令服务器，向目标车载终端的连接通道上，发送9101指令，通知目标车载终端开始传输音视频。
3. 车载终端在接收到9101指令后，通过指令消息体里所包含的流媒体服务器的IP与端口，建立一个新的连接，开始传输音视频。
4. 流媒体服务器将收到车载终端发过来的音视频数据包，完成解析并且通过各种流转换，重编码、封装成可供前端播放的音视频流。
5. 用户前端开始播放流媒体服务器所提供的音视频流。

实时音视频

下发9101指令

1078指令服务器负责下发9101指令来通知车载终端开始音视频传输，由协议定义的消息体包含以下内容：

数据类型说明

1. 音视频：表示车载终端发上来的消息包里即有音频数据又有视频数据。
2. 视频：表示只会发送视频类数据包。
3. 双向对讲：在这个模式下，连接为双向通道，车载终端会发送音频消息包上来，流媒体服务器也可以主动下发音频消息包下去，终端会播放出来。
4. 监听：没有用过，应该是车载终端只发送音频，但不接收流媒体服务器下行的数据包。
5. 中心广播：不知道做什么用的。
6. 透传：1078协议不止是用于音视频传输，还可以用于第三方设备的数据采集传输，就比如车辆上安装了一个陀螺仪，可以使用1078协议传输到服务器端来。

码流类型说明

1. 主码流：一般为704x576的分辨率，传输数据量较大。
2. 子码流：一般为352x288的分辨率，传输的数据量很小，大概是1分钟1M字节的数据量。

音视频流媒体服务器

流媒体服务器是我们这个协议中的主体，是完成对音视频传输的数据对接，到转码、封装为新形式音视频，以提供给用户前端进行播放的关键服务器，涉及到了大量的音视频编解码、分布式架构、各种网络协议方面的知识。

在这里，我们主要要完成对RTP消息包的解析，从中分离出音频或视频的数据体，并且完成解码或重装封装的工作，如果可能，还需要提供音视频流的订阅，以供给用户前端来播放。

RTP消息包

1078在定义音视频传输消息包时，借鉴了RTP协议，但又不是完全一致，而且里面还有很多不清楚以及有错误的地方，这里是重中之重。协议文档里的定义如下：

我做了一个对于此消息类型的解析工具，见：https://www.hentai.org.cn/format/

RTP协议的定义是有缺陷的，因为实时音视频和历史音视频传输时，使用的RTP消息包格式完全一致，而每个连接通道我们只能够使用消息体里的SIM卡号和逻辑通道号作为标识，导致我们无法正确的区分现在连接到流媒体服务器上来的到底是实时还是回放，所以一般做法是，实时音视频和回放这里，分开两个不同的服务器端口来提供服务。

另外，视频编码一般，或者说几乎所有的终端使用的都是H.264编码，好像有群友碰到过AVS编码的。而音频编码最常用的就是G.711A、G.711U、ADPCMA以及G.726这四种，比较头疼的是，终端经常搞鬼，有时间消息体里传递过来的音频编码与实际的不相符，对于这种情况，最好是在服务器端做配置设置，不以终端的标识为准，以服务器端配置的来。四种常见的音频解码，我提供了acodec音频编解码库项目，大家可以参考一下（目前只支持G711A、G711U、ADPCM的解码）。

还有一点，使用了海思音频芯片的终端（比如锐明的终端），音频数据体通常会带上海思头，它的形式如00 01 XX 00，XX表示后续字节数的一半，如果碰到符合这个规则的前四个字节，直接去掉就可以了。

音视频编码与封装

在这一步里，我们需要完成对已经读到的音频或视频的解码封装的工作，车载终端传输过来的音频或视频，用户前端的浏览器或APP不一定能够直接播放，通常需要封装为其它形式。最佳的办法是提供RTMP+HTTP-FLV，这样的话，网页端可以使用flv.js进行播放（摆脱对flash的依赖），而APP端或小程序等，可以播放RTMP流媒体。最简单的办法是，使用ffmpeg将视频直接推流到RTMP服务器，这里推荐nginx-http-flv-module这个流媒体插件，ffmpeg完成将视频推送，而身为RTMP服务器的nginx-http-flv-module除了接收RTMP推送，同时还能够将RTMP流转为HTTP-FLV流，同时兼顾两种形态的流媒体。

而音频就比较麻烦了，ffmpeg虽然可以将音频和视频整合推流（参考FFMPEG入门与集成开发指南），但是里面有太多不可控制的因素了，我项目里的multimedia分支就做了这个尝试，但是效果很糟糕，而有的群友就很成功，不推荐这个办法。如果需要音频，建议默认只开启视频，需要音频时，再发送指令开始传输音频再传输到用户前端进行播放。

音视频流的订阅

实时音视频流是可以共享的，也就是说，对于同一辆辆的同一个通道的音视频，是可以有多个用户同时播放观看的，而历史音视频不行，必须是独占的。如果在流媒体服务器上直接提供音视频的话，则需要控制好这一点，而如果使用了比如nginx所提供的RTMP服务器，就不需要另外考虑，流媒体天生就是一对多的。

历史音视频回放

因为RTP消息包结构只有SIM卡号和通道号可以作为通道标识，而无法区分是实时音视频还是历史音视频，所以通常我们另外开启一个TCP端口监听来为历史回放提供支持。

在官方文档的0x9201指令消息体里，文档里有错误，快进或快退倍数重复了两遍，忽略掉这个小错误，只写一次即可，切记切记，其它的流程里，就与实时音视频一样的处理就可以了，里面有一点要注意的是，历史音视频的传输速度会以终端的最大带宽进行传输数据，比较典型的结果就是，如果车载终端目前已经传输了5分钟的数据量了，而用户前端只播放到30秒，那此时对车载终端下发回放控制指令（如快进、暂停、seek定位等）可能会很久以后才会响应到，最好就是在发送播放控制指令后，清空流媒体的缓冲数据，或是干脆重建流媒体，或是控制服务器端的接收速率，让它能够尽快的响应过来。

双向对讲

双向对讲模式下，车载终端与流媒体建立的连接通道将是一个双向通道，终端将采集上来的音频编码后发送到服务器端，服务器端也可以通过这个连接通道发送音频数据下去，终端将完成播放。

首先，下发的消息包，结构也是按照上面的RTP消息包结构来的，需要注意以下事项：

1. SIM卡号不能错
2. 通道号，大坑，建议先按协议标准定义的36测试一下，不行的话，就从1开始，一直试到255为止。
3. 时间戳不能错，要按照实际的时间间隔来递增，建议直接从0开始。
4. 音频编码，终端是什么编码，服务器下发的时候，就应该是什么编码，不对等的音频编码没有测试过。
5. 发送的速率不要太快，如果一个消息包的音频数据时长为20毫秒，那发送下一个消息包也应该在20毫秒以后，终端通常会全速播放，不一定会按时间戳来慢慢播放。
6. 如果发上来的音频数据里有海思头，那下发的音频数据体也应该加上海思头。
7. 终端音频的采样率都是8000，不用考虑其它的采样率。

语音对讲比实时和历史音视频的坑要大得多，一定要注意多测试，并且控制测试的粒度，不要把用户前端的录音到传输到流媒体服务器等整个链路一起来测试，应该直接准备一个PCM数据文件，直接进行分包下发测试，听到终端的声音后再考虑完整的流程应该是怎么样去规划。

音视频上传

协议里要求的历史音视频上传的接收端，必须是一个FTP服务器，在架设FTP服务器时，注意PASV被动模式的端口问题，FTP服务器通常使用21号端口提供指令服务，同时还要提供一个端口范围段，来提供数据交换服务。

协议里的0x9206指令消息体里，文件上传路径是一个关键性的字段，应该把这个字段与用户请求关联起来，建议使用 /{UUID}/ 这样的值（这个路径是相对于FTP根目录的一个路径，终端会通过协议自动创建），当车载终端上传完成后，它还会再次主动上报上传结果的，这个时候我们就可以知道应该去FTP的哪个目录下去读取媒体文件了。这里还要注意一件事，终端上传到 /{UUID}/ 目录下的文件可是千奇百怪的，什么样的命名都有，什么编码的都有，而且通常是好几个文件，建议直接取大小最大的那个文件就好，而上传的视频文件一般有h264裸流和mp4这两种，建议在上传完成后，使用ffmpeg转码统一为mp4后再提供给用户。

如果要求提供上传进度功能，可以参考我的FTP代理服务器项目：ftp-proxy-server

前端播放

上面建议使用nginx-http-flv-module，它可以支持RTMP的推流，同时可以提供RTMP流媒体、以及HTTP-FLV的支持，在网页上，可以使用flv.js来播放，在移动APP端就可以使用RTMP来播放，相信各位可以很容易找到支持RTMP协议的播放器，这里就不细说了。

其它问题

关于延迟

1. 累积延迟：flv.js有累积延迟问题，它在播放的过程中，会越来越落后于视频流的进度，这里应该定期的清空MSE的缓冲，在我的开源项目的multimedia.html里有示例可以参考。
2. 视频延迟：如果用户前端的首屏时间为1秒，而视频画面上看到的时间OSD文字为几秒或几十秒之前，这是终端的锅。首屏时间有多长，视频延迟就应该有多长，这才是正常的，因为我们的流媒体无法创建出视频出来。

flv.js的并发

chrome浏览器对于同一个域名的并发连接是6路，而HTTP-FLV是基于HTTP协议的长连接，一般不注意的话，很容易误以为流媒体服务器有什么并发上的性能问题，其实这是浏览器的锅，这里建议使用多域名或是多端口号来避开浏览器对单域名的并发数的限速。

写在最后

本文档写了差不多两天，断断续续的，很多地方也还没有写清楚，还只是把常见的一些问题和简单的流程写了一下，还有很多实现上的细节需要了解的，可以进群交流，群里各种语言的开发者都有。

附录

JT 1076-2016营运车辆车载视频终端音视频通道定义表

注意：实际上车辆在安装摄像头的时候，并不会遵照通道号的要求，很多都是乱七八糟的接，线只要接上就行了，所以通道号的对照表没有什么用。另外，最重要的一点，如果要做双向对讲，是需要在消息体内声明逻辑通道号的，这里我建议先按协议要求的试一试，如果不行就从1试到255，因为有家厂家我记得使用的驾驶员音频通道号是99。

音视频编码类型定义表

参考资料

1. jtt1078-video-server
2. 1078音视频协议分析工具
3. 音频编码知识基础
4. acodec音频解码库
5. FTP代理服务器
6. FFMPEG入门与集成开发指南
7. 交通运输标准化信息平台（所有部标协议文档下载）