机车车载视频数据自动归集技术研究及应用

慕元鹏

（北京纵横机电科技有限公司，北京 100081）

0 引言

近年来，为了进一步加强铁路运营安全管理，方便责任事故取证，机车车载视频监控系统已经成为新造机车安全装备的标准配置。在和谐系列机车上，该系统包含在机车车载安全防护系统（6A系统）中[1]；而其余保有机车也在近几年内陆续进行了车载视频监控系统的加装。当前国内运营机车数量超过2万台[2]，每天产生海量的视频数据，使得视频分析岗位人力的需求急剧增加。机车视频数据的高效管理和应用成为机车安全管理关注的重点。目前，我国机车车载视频监控系统应用中存在以下3个方面的困难：首先，机车视频监控系统的供应商数量众多，各厂家在视频编码、封装上均有不同，甚至在文件格式上也不一致，导致联动调取播放时，通用视频播放器无法对所有视频数据解码，这给视频数据的管理和应用造成了不便；其次，不同规格的视频监控系统的视频数据质量不一致，尤其是视频完整性方面，无法及时知晓视频是否缺失；最后，视频数据中的时间戳异常，会造成联动分析不同步的问题，可能导致检索和举证困难。

本文通过对机车车载视频监控数据自动归集技术进行研究，设计了一种多维度的视频数据自动归集技术方案；通过对多种不同格式视频数据进行批量编码、封装转换，同时进行视频完整性检查，实现系统参考时钟和显示时钟标签的同步修正；最后利用大容量无线数据传输链路将转码后的视频数据传输至地面服务器。该技术目前已被成功运用到国内多个路局的机务信息系统中。

1 方案功能架构

机车车载视频数据的自动归集涵盖了视频数据无线车地传输和视频数据的格式归一化，其中超大数据量的视频文件需要通过无线网络传输至地面服务器，主要存在传输速率的限制瓶颈问题。4G移动数据链路只能实现约8 Mb/s的传输速率，基于802.11n格式的WLAN可以提供最高约为300 Mb/s的传输速率，而当前最新的5G技术可以支持10 Gb/s的传输速率。因此，在车地传输的方案上，5G链路是突破传输速率瓶颈的有效选择。视频数据的归一化目标是将不同厂家和不同编码、封装格式的视频数据转换为统一目标格式的视频数据，为后续应用提供清晰易用的结构化数据。本文采用视频编解码领域内最为通用的多媒体视频处理工具库—FFmpeg作为编解码库的基础进行通用转码功能的开发，以确保编码格式的标准化。为加强技术的实用性，采用分布式并行批量转码的方式来提升转码效率，并增加对视频数据的时钟修正和完整性检测。

2 视频数据归集和编码转换

2.1 视频数据自动归集

不同厂家的车载视频监控设备采用的数据管理方案存在较大差异，同一个路局所配属的机车往往有多家视频系统供应商。因此，目前主流的视频数据归集方法为工作人员上车使用USB设备进行数据下载，之后再拷贝至地面服务器上。这种方式工作效率较低，在机车整备或者机车返回机务段的高峰期，无法将全部的视频数据导入到服务器中。如何将数据经通用接口快速实现车地传输是解决问题的关键。

考虑到机车车载视频监控系统均具备网络接口，可以通过该接口，构建统一的FTP服务，在机车运行时就进行数据的中转；然后由视频数据中转设备建立与地面服务器的高速无线网络链路，当机车进入机务段的无线接入点（access point, AP）覆盖范围时，中转设备中的视频数据一次性通过高速无线网络传输至地面服务器，实现不同型号车载视频监控数据的自动化归集。

2.2 转码目标格式

目前，国内铁路机车实际运用的视频监控数据编码格式分类情况如表1所示。

表1 国内机车视频监控数据编码格式分类Tab. 1 Classification of domestic locomotive video data encoding format

视频转码的目标格式需要有足够好的兼容性和通用性，一方面要能够使用通用播放器进行播放，并支持浏览器直接进行解码播放，以满足B/S架构下的系统灵活联动；另一方面，需要具备统一且标准的文件格式和高效的目标转码效率。综合以上考虑，本文选择H.264格式作为视频目标编码格式，AAC格式作为音频目标编码格式，MP4作为最终文件存储格式。

2.3 编码及封装转换

根据表1可以看到，视频数据在视频、音频、封装和文件格式上存在多种组合。其中封装格式和文件格式不涉及视频数据的重新编解码，只是在原始数据上增加结构化标识和容器外壳。实际上，机车车载视频数据均采用了节目流（PS）或传送流（TS）格式的封装，并直接存储为非标准的MP4格式文件。因此，对于不同的视频文件，首先需要使用FFmpeg对视频文件进行解封装，之后再单独对视频和音频部分的码流进行处理。

2.3.1 视频转码

各个视频监控系统厂商对视频码流部分的编码均采用了统一的标准格式，即使用H.264格式进行编码，主要的差异体现在分辨率和帧率。分辨率不同的问题可以通过在展示播放时按比例拉伸来保证视频播放画面的大小一致，因此，可以不在转码过程中进行调整。帧率不同问题会影响到多画面快进、快退和联动播放的同步，就需要在转码时通过对低帧率视频进行插值补偿或者对高帧率视频进行抽帧来解决。兼顾到机车运动时图像的流畅性和车载存储器存储空间的限值，将视频的帧率统一转换为15 f/s。对视频码流进行转码的流程如图1所示。

2.3.2 音频转码

图1 视频转码流程Fig. 1 Flow chart of video transcoding

在机车车载视频数据中，音频码流的转码所需要应对的情形更加复杂，涉及了多种音频编码格式，主要包括AAC，PCM，MP2及MP3等。尤其是在一些早期的车载视频监控产品中，部分厂家使用了PCM_MULAW的音频编码格式，由于FFmpeg对此种音频编码格式难以正确识别采样精度，导致在选择音频解码器时出现采样位数不匹配问题。一般情况下，当前主流设备都采用16 bit的采样精度，但实际运用过程中，发现了部分视频采用了较为少见的8 bit采样精度。在进行转码时，若直接使用FFmpeg的自带接口，则会自动进行音频解码器选择，默认采用16 bit采样精度的PCM解码器解码，会出现采样率下降的问题，导致音质下降和更多杂音，视频的长度也会因此发生改变。因此，在进行音频编码转换时，如果检测到采样率异常，需要及时指定音频解码器来正确地解码不同编码格式的音频码流。音频码流的转码流程如图2所示。

图2 音频码流的转码流程Fig. 2 Flow chart of transcoding audio stream

完成视频码流和音频码流的编码转换后，视频码流转为统一的15 f/s帧率的H.264格式视频编码；音频码流转换为统一的采样率为8 000 Hz、采样精度为16 bit的AAC音频编码，且均使用MP4标准容器进行封装。

3 批量转码和时钟修正

机车车载视频监控系统监视多个车内外区域，通常采用具有8个以上通道的摄像头，正常情况下每台机车每天产生的视频文件数量接近1 000个。当前主流的CPU大多采用了多核架构，可以充分利用计算资源提升转码效率，采用并行方式进行转码是一种较为理想的选择。同时，为了在视频数据关联分析时能够与机车运行安全监控系统（LKJ）信息实现同步，需要对视频文件的绝对起始时间和SCR（system clock reference）时间进行修正[3]。

3.1 批量转码

在进行批量转码时，为了避免各个转码任务之间的干扰以及个别转码过程中出现异常时对整个系统的影响，本文采用多进程的方式来实现并行转码。在进行多进程转码时，根据不同硬件环境进行进程控制，实现自适应的CPU占用平衡，避免同时开启过多进程，引起计算机卡顿。

多进程控制流程如图3所示。首先，使用CreateTool help32Snapshot( )函数创建进程快照，按照信息进程结构体PROCESSENTRY32、利用函数Process32First( )来循环查找转码进程，得到当前在执行的转码进程数量；然后，通过获取配置文件中的转码并行进程数量限制值来确定是否需要启动新的转码进程，同时获取CPU的占用情况，当占用率超过80%时，不再允许开启新的转码进程；最后，在上述条件的限制下，将待转码视频文件列表中的文件逐个进行转码。重复进行上述操作，直至所有的待转码文件完成转码。

图3 多进程转码控制Fig. 3 Multi-process transcoding control

批量转码时，还需要特殊考虑暂停和续转问题。批量转码的过程中，可能由于某些资源需要切换，必须暂停转码，并在合适的时间恢复原有的转码进度。另外，考虑极端情况，软件出现异常退出时，也需要在下次启动后恢复原来的转码进度。为此，本文提出一种基于转码过程文件和共享文件列表的暂停和续转控制方法，即在启动转码前，首先生成一个临时的待转码文件列表并写入本地磁盘的文件中，该列表文件以共享读写的形式打开（为支持外部程序进行待转码文件列表导入，此文件被设定为共享模式）；所有待转码文件被读出后，以路径列表的形式同步保存在转码软件的内存数组和待转码文件中，每完成一个文件转码的同时剔除相应的一行列表；然后，创建一个转码过程文件，将转码过程状态数据实时写入到此转码过程文件，每完成一个文件的转码就记录一行转码状态，实现转码过程的跟踪。

转码过程文件按照序号、操作类型、待转码文件路径、视频总时长及操作完成时间进行组织，中间使用“.”符号进行分割，便于在读取时进行自动字段的提取。

当需要暂停转码时，把前文所述的转码并行进程数量限制值置为0，则不再有新的转码进程被创建；等待当前所有进程退出后，自动进入到完全的暂停状态。恢复时，重新读取待转码文件列表共享文件，则可以启动转码并继续原来暂停的转码进度。若不需要进行续转，只需清空待转码文件列表即可，转码软件将自动按照新的转码文件列表开始新一轮转码流程。

3.2 时钟修正

视频文件绝对起始时间的一般来源为视频文件创建时记录下来的系统时间，而车载硬盘录像机（DVR）模块可能因为某些原因而导致系统时间不准确；其另一个来源则是提取视频内容，以光学字符识别（OCR）方式识别出视频实际时间[4]，即在进行转码前，截取视频文件中最早的5个关键帧（I帧），裁剪出字幕中的时间图片进行5次OCR识别，并转换为标准时间。通过对系统时间与OCR获取得到的时间进行比对，确认最终的视频文件的绝对起始时间。通过OCR方式获取的时间信息如图4所示。

图4 OCR时钟提取Fig. 4 OCR clock extraction

考虑到可能会出现随机断电、磁盘坏块等异常终止录像的情况，大部分车载视频监控系统采用了视频码流直接封装存储的方式。切换视频文件时，SCR时间未进行置位，导致第一帧的SCR时间就是系统启动之后的运行时间。该时间会影响视频数据联动时的定位和播放。

为了避免时钟值溢出，在进行视频数据转码之前，需要对原始视频中的SCR时间进行校正，通过逐帧读取的方式将每一帧数据的SCR时间减去第一帧数据的SCR时间，最后再填充回原来的PS_head_tag标准结构中；同时，按照对应的时钟值修正PTS（presentation time stamp）时间。这样处理之后的视频文件，在进行关联时，就能够很方便地通过时间戳与其他机车运行状态数据同步。

4 视频完整性检测

机车视频监控数据的运用中需要考虑数据的质量，其中最重要的指标是视频的完整性。车载视频监控系统受到传输网络和存储器状态的影响，无法确保在任何时刻都能够完整地记录所有视频数据，在批量很大的情况下，部分时段视频的缺失往往是较为常见的现象，而这类缺失对于后续的联动分析应用有很大的影响，因为视频数据与LKJ数据的关联主要通过时间戳的映射来实现。

这种影响主要体现在视频文件的总时长上。视频文件在创建时会记录开始创建的时间，但其结束的时间则存在不确定性，因视频监控系统可能存在临时的断电或者由于软件异常等原因造成视频文件重新创建的现象。单个文件的总时长在转码时使用FFmpeg就可以获取得到，但这个数值受到原始数据编码时填充的时间戳的影响，文件尾部可能并不完整，得到的可能是一个错误的数值。为了对文件的总时长有一个更为准确的比对，本文设计的方案是采用第三方开源媒体信息库mediainfo来进行视频媒体信息的提取，提取得到的总时长再与转码过程中通过FFmpeg获取的总时长进行比较，最终确定文件总时长的准确值。

视频文件中单个帧损坏或者连续多个视频帧缺失也会影响到视频监控数据归集应用和后续的联动分析。对于这类情况，在进行视频转码时，需要分别对单个数据帧和多个连续数据帧进行检查。

4.1 单个数据帧的完整性判断

通过逐字节读取视频数据文件，并找出第一个PS视频数据帧的包头起始标识码00 00 01 BA，按照标准的PS_header_tag结构体检查数据帧包头部分是否存在错误或丢失现象。若存在，则直接记录当前文件名和上一个正常数据帧SCR时间；若数据包头正常，取出当前数据帧包头中的帧长度和该数据帧的相对时间信息（每个视频数据文件起始时间为0），继续读取文件，直至下一个数据帧包头起始标识码。将实际数据帧长度与包头中记录的长度进行比对，若一致，则说明该数据帧完整，重复以上过程；若不一致，则丢弃该数据帧并记录当前文件名和本数据帧时间，继续寻找下一个PS视频数据帧包头起始标识码。单个数据帧的完整性判断流程如图5所示。

图5 单个视频数据帧的完整性检测Fig. 5 Integrity detection of a single video data frame

4.2 连续多个视频帧缺失检查

首先，根据视频数据帧率设定帧间时间差阈值。为避免出现误判并保证较好的检测效果，考虑到机车车载视频监控系统的常用帧率为15 f/s，且人眼对于200 ms以下的单个相近画面不敏感，将帧间时间差阈值设置为(单位：s)、最大连续不完整数据帧阈值为。如机车车载监控系统视频数据的帧率为15 f/s，则帧间时间差阈值可以被设置为3/15=0.2 s，最大连续不完整数据帧阈值则被设置为2帧。在完成单个视频数据帧的完整性分析后，使用上述两个阈值进行判断，若超过阈值范围，则记录当前超出阈值相应的文件名、帧相对时间，并以SCR起始时间为参照，计算出视频间断时间点，以excel表格的形式存储。该表格在关联分析时将被作为索引输入导入到数据库中。视频数据完整性检测流程图如图6所示。

图6 连续多个视频帧缺失检测Fig. 6 Missing detection of consecutive multiple video frames

5 方案应用

目前，本文所述机车车载视频数据自动归集技术已经开始在部分铁路局进行试点应用。利用该技术，车载视频数据可以在前端完成分布式并行转码，极大提升了转码效率。转码后的视频文件，在机车回段时，通过大容量数据传输装置实现高速车地信息传输，最终在路局的数据服务器中实现归集。

5.1 车载GPU转码

当前国内各铁路局对机车车载视频监控数据的转码主要方式为地面集中式转码，即通过司机退勤时将车载外挂转储U盘中的数据拷贝至机房进行转码。这给机房的计算机造成了较大的转码负荷，且转码时间较长，不可避免地会出现排队的现象；而车载嵌入式处理器CPU则受限于功耗等原因，计算能力不足，所以也难以将十分消耗计算资源的转码工作移至机车上完成。

针对视频转码业务，图形处理单元（graphic process unit, GPU）在性能上比CPU具备更大的优势。在工业嵌入式领域， NVIDIA公司发布了一款JETSON TX2型GPU，其额定功耗只有约7.5 W。经过测试，TX2的视频转码效率可以满足现场运用要求（转码效率大于10 MB/s），单台机车8个视频通道1 h产生的视频文件一共32个，大小总计约为2 GB，TX2可以在2 min内完成1 h视频到标准MP4的转码。

TX2通过以太网与车载视频监控系统通信，使用FTP协议获取视频文件数据，然后进行转码并保存在临时的硬盘存储器上；待条件满足时，借助于大容量无线通信链路传输至地面服务器。

在大数据技术快速发展的趋势下，车载视频转码的主流方案已经更加倾向于将计算工作移动到云端进行，也就是实现边缘计算。本文借助这个思路，把转码流程安放到车上进行是一种更为高效和可靠的解决方案。

5.2 无线大容量视频数据传输

车载视频监控系统视频数据的落地一直是难以解决的问题，通过移动数据3G/4G业务进行传输，需要负担高昂的流量费用，而传统的WLAN只有在段内可以提供无线AP热点接入，且机车在短时间内无法完成全部视频数据的传输，不具备实用价值[5]。

为解决此问题，中车株洲电力机车研究所有限公司设计开发了一套大容量视频数据传输系统[6]。该系统包含一个带有嵌入式Intel 酷睿I7处理器、总存储容量1 TB固态硬盘的机箱，以及一个高速WLAN天线。WLAN天线与通信设备厂商合作开发，具备千兆带宽容量，实际传输速率可以达到100 MB/s，使用PoE方式为天线供电。该大容量视频传输系统拓扑结构如图7所示。

图7 大容量视频传输系统拓扑结构图Fig. 7 Topological structure of the large capacity video transmission system

大容量视频数据传输主控板卡直接访问已经完成转码的视频数据，机车进入机务段时，自动接入地面的无线AP热点并触发视频数据的传输，通过FTP协议将视频数据转储至地面服务器上。经过测算，机车车载视频监控系统每天的数据量在30 GB左右，传输完所有视频文件大约只需要5 min。这样，在机车进入机务段的过程中，基本上就可以完成全部的视频从车载设备到地面服务器的传输，大大减少了路局在视频数据统一管理和应用上的人力资源投入。

6 结语

在机车应用由信息化向智能化迈进的过程中，车载数据的归集是当前最为关键的一步。利用视频转码技术和大容量数据无线传输技术来解决机车车载视频监控数据自动归集是一种具备较强可行性的方案。

本方案中，视频转码技术将机车车载视频数据的不同编码格式和封装形式统一成标准的MP4文件，修正了影响关联分析的视频数据时间戳，形成每个视频通道在全时段范围内的数据索引，整个过程通过车载GPU板卡在机车运行过程中完成。视频数据导入数据库时，不再需要通过重新对文件读取来构建数据索引，节省了地面系统集中转码的时间，加快了视频数据从下载到归集进数据库的过程。

通过大容量数据无线传输技术，将完成转码的视频数据在机车进入机务段停靠的很短时间内就可以完成从车载到地面服务器的下载，减少了人力资源的消耗，也避免了人为因素对视频监控数据造成影响的风险，在高效和安全性方面对于路局的信息化运营管理具有重要意义。

车载GPU视频转码及大容量视频无线传输技术，是对海量数据转换和车地传输的一种有效尝试，其已被装车试用，成功解决了大容量视频数据的结构化和高速无线传输问题。随着未来公网5G技术的推广应用，有望将大容量数据传输从站段AP接入方式升级为全线实时专网传输，从而更好地支撑高清甚至是超高清车载视频系统在机务信息化工作中的推广应用。