基于软件中间件的多类型视频编码板兼容性设计

张 平

（株洲中车时代电气股份有限公司，湖南 株洲 412001）

0 引言

在进行复杂视频监控系统的设计、构建和维护过程中，经常面临部件的兼容性问题。复杂视频监控系统往往需要兼容不同类型的底层非自研部件，以实现良 好的互换性［1］。但是，由于不同供应商对于同一部件的设计思路存在差异，而且将其内部的实现原理作为商 业机密进行保密，这就不可避免地造成视频编码板在 应用层与不同供应商所提供的底层软、硬件不兼容。

成熟的产品一般通过起草产品标准的方式来实现接口和协议的统型，但在产品的实际应用过程中，难以达到部件级的统型和互换［2-3］。而直接对上层软、硬件 设计进行改动，可能会降低整个产品的稳定性，大大增加技术风险，尤其是在检修过程中，无法进行部件级替换，整体替换则会带来高昂的检修成本［4］。因此，尽可能利用软件方式来处理底层软、硬件设计差异，是最有优势的方案。为此，针对机车车载安全防护系统机车自动视频监控及记录子系统（简称“6A 视频子系统”）编码板的兼容性问题，本文提出基于软件中间件的多类型视频编码板兼容性设计方案，从板卡识别、视频码流获取、关系解耦、差异注册以及动态库加载等方面分析研究，设计了一个独立的软件中间件，在上层软、硬件无改动的情况下，实现多个类型视频编码板的兼容。

1 6A视频子系统

6A 视频子系统主要实现机车各个监控区域的视 频数据采集、传输、存储和显示等功能。该系统通过记 录司机室、机械间等位置及前方路况的视频信息，并关联机车运行状态数据，为机车运用过程中的故障和事故分析提供重要依据。

1.1 系统构成及原理

6A视频子系统主要由视频采集模块、视频编码模块、视频处理模块和视频显示终端组成［5-6］。视频采集模块通过同轴模拟信号与视频编码模块连接，视频编码模块、视频处理模块和视频显示终端通过以太网交换机建立局域网链路。6A 视频子系统的架构如图1所示。

图1 6A 视频子系统架构Fig.1 Architecture of 6A video subsystem

视频采集模块包括前端摄像机系统及接口，为视 频编码模块提供实时视频信号。为了覆盖机车各个关键监测部位，视频采集模块支持14路摄像机和2路音频。摄像机采用同轴电缆与视频编码模块连接。

视频编码模块由一块或者多块视频编码板组成，接收来自视频采 集模块获取的视频信号，并对其按指定格式（如 H.264、MPEG等）进行编码，同时将信息叠加和编码压缩后的码流通过以太网发送至视频处理设备，如视频处理模块和视频显示终端。

视频处理模块由板载计算机系统和大容量存储单元构成，主要完成视频码流的处理和记录存储，并为视频系统的控制和参数设置提供相应的服务；视频显示终端通过以太网接收来自视频编码模块的视频码流，对视频码流进行解码后，将实时的视频图像显示在视频显示终端上［7］。

1.2 兼容性设计的需求分析

在设计视频编码模块时，各厂商通常会对视频采集端摄像头进行兼容性设计，确保输出 PAL 或 NTSC 制 式的标准信号，兼容常规的视频编码格式（如H.264、MPEG），实现摄像头的互换性［8］。但不同品牌的视频编码模块、视频处理模块和视频显示终端往往根据自定义私有协议进行通信，形成了各模块间的交叉依赖和绑定关系。当需要替换其中一部分模块时，必须采购同一品牌的产品才能进行替换。解耦这种绑定关系并实现各个部件之间的完全兼容替代，是视频监控系统持续走向标准化和互联互通的关键［9-10］。

完全的兼容意味着可以实现任意部件的动态更换，这就要求视频编码板在系统运行过程中，可以通过热拔 插的方式进行更换，并确保系统的功能得到立即的恢 复［11］。通过分析6A视频子系统的架构和关联关系可以发现，要实现部件级的替代，主要的困难就是在如何实现视频处理模块与不同类型的编码板之间的兼容。

2 视频编码板兼容性方案设计

由于设计思路和理念的不同，不同类型的视频编 码板在硬件上和软件的实现原理上通常都有着较大的差异。为了保证6A视频子系统在多块不同类型视频编码板的情况下能正常工作，首先需要对不同类型的编码板进行识别；其次，需要对这些视频编码板分别进行资源加载、初始化以及视频码流获取，以实现不同视频编码板关系上的解耦。

为了达到视频编码板的兼容，在视频系统设计时 可以从电气接口、通信协议和软件调用接口等方面直 接进行严格约定来实现；但实际操作上，受限于市场中各个互相竞争厂家可以接受的开放程度及项目已经大量投入使用并进入维护检修周期的现状，这些方案难 以被推动。而另一种方式，就是在软件层面上构建一个中间件，将已经定型和应用的软硬件、接口和协议上的差异进行屏蔽，提供统一的操作接口。为此，本文所设计的方案中开发了一个名为Midware.dll 的软件中间件动态库。

2.1 编码板类型识别

6A 视频子系统中，视频编码板通过以太网交换机与视频处理模块连接，使用用户数据报协议（user datagram protocol，UDP）建立通信链路，模块间的通信机制如图2所示。

图2 编码板与视频处理模块/视频显示终端间的通信机制Fig.2 Communication mechanism between encoding boards and video processing module/display

首先，视频处理模块或者视频显示终端程序通过 socket 与视频编码板建立UDP 连接，并向视频编码板 发送请求报文；然后，视频编码板周期性地向视频处理模块或者视频显示终端发送编码板类型信息报文；最后视频编码板收到应答报文后停止发送编码板类型信息报文。若视频编码板无法收到应答报文，则会在连续发送10个周期（每个周期1 s）后，停止发送编码板类型报文，并将故障指示灯点亮，提示需要重新拔插板卡以恢复正常功能。

经过一个完整的通信流程，视频处理模块或视频显示终端可以获取当前接入系统的视频编码板的类型信息，为后续对板卡进行视频通道初始化和动态库的调用提供依据。

2.2 视频编码板之间的解耦

通过视频编码板与视频处理模块和视频显示终端的通信，6A视频子系统可以获取到当前接入系统的视频编码板类型信息。当视频编码模块只由一种类型编码板组成时，为便于对多块视频编码板在软件上进行统一的管理，通常视频处理软件对多块板卡的操作是同时进行的，比如，对视频编码板进行视频通道初始化和视频码流获取等操作。但随着6A视频子系统的长期应用和维护，可能会存在多种类型编码板混用的需求，在这种情况下，需要对不同类型的视频编码板进行独立的操作，以避免出现冲突。

从系统集成的需求层面，各编码板提供的基本功 能是没有差别的，在硬件接口上也容易保持一致。在既要保证当前系统能够同时兼容多个类型的编码板，又要尽可能减少软、硬件修改工作量的情况下，可以在 程序中涉及针对不同板卡需要独立进行操作的函数中引入enc变量。其中，enc=1，代表编码板1；enc=2，代表编码板2；多块编码板存在时，可以依次类推。将此值保存在各不同类型编码板中，建立一一对应的规则，以后在每次对编码板进行操作时，均需提前判断该变量的值。如此，在进行故障替换和检修维护时，可以做到6A视频子系统中不同类型编码板混插的完全解耦，解耦前后差异如图3所示。

图3 不同类型编码板关系解耦前后对比Fig.3 Comparison of different types of encoding boards before and after relationship decoupling

图4 动态库调用机制Fig.4 Dynamic library call mechanism

2.3 差异化接口函数动态库加载

6A 视频子系统中只有唯一的编码板类型时，对相应类型编码板提供的动态库av_codec.dll 加载只需直接进行即可，甚至可以将动态库av_codec.dll在编译时进行无需指定的隐式加载，接口函数通过av_codec.h头文件进行声明引入视频处理程序中。当存在多种类型的板卡时，就需要按照不同类型的板卡来加载对应的动态库。为满足各编码板为不同类型的板卡时的情况，还需要对所有视频编码板的动态库进行分别加载，这个加载的过程都由Midware.dll中间件来完成。

类型数量的增加也意味着动态库数量的增加，为 了便于维护并保持程序调用结构的清晰，只将 Midware.dll.存放于程序当前目录。如：将针对3种类型的动态库分别存放在程序当前目录下的01、02和03目录，动态库分别命名为av_codec1.dll、av_codec2.dll 和 av_codec3.dll。Midware.dll 根据对板卡类型信息的识别结果，决定调用哪一类型视频编码板所对应的动态库，动态库的调用机制如图 4 所示。

3 视频取流和编码板动态替换设计

经过类型识别和编码板关联关系的解耦，再对视 频编码板分别按照对应类型编码板的接口动态库进行加载，调用对应的视频通道初始化函数，最终通过不同的函数接口，实现不同类型编码板的视频码流获取。在实际运用中，为了保证数据记录的连续性，通常不允许对系统进行断电，只有支持直接对视频编码板进行 带电拔插和替换，才能达到上层应用与底层软、硬件的完全兼容。

3.1 视频码流的获取

在视频编码板上电之后，需要对视频通道进行初始化，准备好系统缓存和操作句柄资源，以及对视频通道号、分辨率、码率、帧率等关键初始的设置参数进行赋值，最后才可以调用匹配的动态库函数获取视频码流。不同类型的视频编码板，其视频通道初始化操作可能会不一样，因此，需要进行不同的视频通道初始化处理。以A、B两种类型的视频编码板为例，在进行6A视频子系统统型的过程中，A 类型的视频编码板采用一次调用同时对所有编码板初始化的方式，而另B 类型则采用分别初始化的方式。此前的系统是对所有编码板一次性初始化，新增B类型编码板之后，如果系统中编码板1 和2 分别是A、B 不同类型的编码板，系统还是认为只初始化一次即可，不再对编码板2 进行初始化，这就将导致编码板2 未初始化，无法正常工作；为了适配新增类型编码板，系统增加对B 类型编码板的初始化支持，但新的问题是：如果编码板1是B类型的板卡，编码板2是A类型的板卡，正常运行过程中重新拔插编码板1（B类型），系统在完成编码板1初始化后将编码板2 再次初始化，这就会出现两次初始化编码板2的问题，导致视频信号中断。

为了解决以上所述问题，在初始化板卡视频通道时，利用获取到各个板卡的类型信息，为每个类型板卡增加一个表示初始化状态的静态变量标识。初始化状态初始值设置为0，首先对编码板1视频通道进行初始化操作，完成编码板1的视频通道初始化后，将该静态变量自增1。编码板2的视频通道初始化在进行视频处理模块或视频显示终端与编码板2 的UDP 通信之后，系统获取到编码板2 的类型信息，如果该板卡与编码板1相同类型，静态变量保持为1，不再进行初始化；如果该板块与编码板1不同类型，则使用新的静态变量，其值为0，系统对编码板2 进行单独的视频通道初始化；每块编码板根据静态变量的状态单独初始化，并进行状态保持，避免多次实现不同类型的编码板导致的重复初始化问题，达到完全的初始化操作解耦目的。其流程图如图5所示。

图5 改进后的视频通道初始化流程Fig.5 Flowchart of improved video channel initialization

完成视频通道的初始化之后，直接调用加载后的 视频码流获取函数，此时加载的函数均可以与不同类 型编码板实现一一对应，视频码流可以被正确获取。后续对视频码流的存储和处理均只在视频处理模块内进行，不再因视频编码板类型的不同而出现兼容性问题。

3.2 动态替换

对于6A视频子系统所使用的各品牌的编码板，当新的板卡被插入机箱接入系统时，视频处理模块上运 行的视频处理软件会检测到该动作，并调用相关函数进行板卡识别，然后对视频通道进行初始化，加载对应类型的动态库。

在对编码板进行动态混插替换时可以发现，当视 频编码板被带电拔出、换成另一块视频编码板时，视频处理模块和视频显示终端都无法获取那块新插入的视频编码板的数据流。对该板卡进行ping操作，可以发现网络也是不通的；但实际上，网络硬件链路上没有任何问题。如果此时对整个系统断电重启，所有不同类 型的编码板都可以正常运行，且网络没有异常的情况。进一步进行测试可以发现，此现象与所采用的视频编 码板的厂家无关，因此怀疑为网络协议上的问题。

经过反复重现该问题，发现在换掉视频编码板时，接入网络的视频处理模块和视频显示终端对视频编码板的IP 和介质访问控制（media access control address，MAC）地址进行了缓存，地址解析协议（address resolution protocol，ARP）将有限数量的IP 地址映射到了它们的物理适配器地址的计算机内存的表中。即当编码板进行动态移除，新板卡又在带电状态下接入系统时，由于新板卡的IP地址与被替换的板卡的IP地址相同，而MAC地址却是不同的，这就会导致在进行网络通信时地址绑定不成功，出现无法接入网络的现象。文献［12］对该问题进行了讨论，并提供了多种清理ARP缓存的方法。

鉴于此，解决该问题的思路就是要在检测到编码 板进行动态替换动作时，清除视频处理模块和视频显 示终端中的ARP缓存，使得新接入的板卡能够被正确 地识别。ARP缓存清理的流程如图6所示。

图6 ARP 缓存清理流程Fig.6 Flowchart of ARP cache cleanup

以本文所述6A视频子系统为例，视频处理模块和视频显示终端均采用XPE嵌入式操作系统，XPE 操作系统自带了一个arp.exe 的命令行工具，可以在检测到新板卡接入系统时在视频处理程序和视频显示终端插件程序中调用命令“arp-d IP地址”，清除系统中对应IP地址的ARP 缓存。但是直接调用命令行程序时，会出现命令行界面弹窗，这在视频显示终端中是绝对不允许的。为此，采用了文献［13］中所述的静默调用方法，以后台运行的方式避免命令行界面的弹出，通过系统函数CreateProcess 创建新的进程，以无窗口显示的方式执行命令行指令，可实现板卡动态替换时，在板卡识别通信之前进行一次ARP缓存的清理，解决了更换板卡后因网络连接失败而无法获取码流的问题。

4 试验验证

视频编码板的兼容性在产品上主要体现在两个方面：其一是不同编码板与视频处理模块和显示终端之间混合运行的兼容，其二是视频编码模块之间动态替换的兼容。为验证所提技术方案的可行性，本文设计了两项不同的验证试验，以确认该方案的实际效果，并选取在业内最具备代表性的3 个品牌（海康HK、大华DH、宇视YS）的视频编码板和2套不同品牌的视频处理模块、显示终端进行试验。

4.1 混合运行兼容性试验

本文对3 个品牌的视频编码板进行交叉分组，以确保不同组合形式的视频系统均可以得到验证测试；同时，设置只含一个品牌编码板的对照组。试验时，根据各个不同组合的顺序，按照图1 的架构搭建视频系统，并使所有模块同时上电运行。

通过视频处理模块和显示终端对系统中各个编码板的视频取流、存储显示、板卡启动时长差异（重复10 次取平均值）进行测试，各测试组合的测试结果如表1所示。可以看出，只含1 个品牌编码板的对照组，由于两块编码板一次初始化就可以完成启动，几乎不存在启动时长的差异，各视频通道可以同时开始记录和显示；混合运行情况下，各不同组合的混合编码板均能够被正确识别，并正常实现取流和存储显示功能，但交叉混合的视频编码板测试组各板卡在加载时间上略有增加，其中，不同视频编码板混合运行时，加载时间有较为明显的增加，造成了一定的启动延迟，启动时差达到了2 s，部分视频通道会表现出稍晚开始记录和显示的现象。

表1 混合运行兼容测试结果Table 1 Compatibility test results in mixed operation

4.2 动态替换试验

试验分别测试了视频编码板在只含一个品牌编码板的对照组以及混插模式下的动态替换效果。通过对上电状态下动态替换板卡后视频处理模块和显示终端对系统中各个编码板的系统恢复所需时长（重复10次取平均值）进行测试，并设置同品牌两个视频编码板的对照测试组，各个测试组合 的测试结果见表2。

表2 动态替换测试结果Table 2 Dynamic replacement test results

动态替换测试的结果显示，只含1 个品牌编码板的对照组进行动态替换时，其恢复时长与动态检测板卡插入的周期（每秒检测）接近；而在混插模式下，在上电状态下的各种动态混插操作，不同品牌的视频编码板重新加载所需时间有所不同，但均可以在3 s内实现对新替换的视频编码板的识别、视频取流和显示存储，满足现场在不断电状态下的视频编码板动态更换要求。

5 装车应用

当前6A 视频子系统在国内“和谐号”机车上装车超过8 000 套，超过6 家供应商提供不同类型的6A 视频子系统，往往在同一个铁路局就存在多种类型6A视频子系统。在没有实现编码板部件级兼容替换时，因混插使用导致的故障十分常见，现场维护工作量大［14］。实际上，最好的情况仍然是在产品设计的前期，从统一技术规范的角度限定方案的设计思路，并在板卡替换的层面上实现统型。对于已经装车应用的产品，采用本文所述的技术方案，则是当前情况下一种相对较好的应对方式。

通过采用本文所提出的多类型视频编码板兼容性设计，可以完全消除混插带来的不利影响，且为各铁路局在应用过程中备品的采购提供更多的选择。

由于采用了完全独立的编码动态接口函数加载机制，所有编码板在运行过程中处于独立的状态，即使个别编码板出现故障，其故障范围可只局限于所辖范围内少数的视频通道，这就大幅提升了系统的可用性和稳定性。此外，得益于本文所设计的动态热拔插加载技术，在检修过程中，对故障板卡的更换可以在不断电的情况下进行，保证了数据记录的完整性。

统计兰州铁路局所有6A 视频子系统应用视频编码板兼容性设计前后1年时间周期的故障率和平均单台车故障处理时长，结果如表3 所示。可以看出，故障率出现了较大幅度的下降，单台车故障处理时间由3 h缩减为1 h。

表3 视频编码板兼容性设计的应用效果Table 3 The application effect of compatibility design for video encoding board

视频编码板的兼容性设计，可为机车C5/C6 修程 下的6A 视频子系统部件检修更换节省大量成本［15］。视频编码板成本约占据整个6A 视频子系统的四分之一，在未采用部件级替换的兼容性设计前，为了适配视频编码板和视频处理模块，不得不大量成套更换6A视频子系统的插件板卡；而采用视频编码板兼容性设计后，视频编码板将可以匹配全部的视频处理模块，且可以混合使用，这就实现了检修成本的大幅下降。

6 结束语

本文以视频系统的部件级兼容替换难题为切入 点，针对机车6A视频子系统，从板卡识别、视频码流获取、关系解耦和差异注册以及动态库加载等方面，设计了一种独立的软件中间件，其在上层软、硬件无须进行任何改动的情况下，可实现多个类型视频编码板产品的便捷互换。本文所提出的技术在国内“和谐号”机车6A 视频子系统中的应用，大幅地提升了维护的便捷性，避免了混插应用带来的兼容性问题，并在检修维保中达到了降本增效的目标。

根据试验得到的结果和实际应用经验，混合运行兼容场景下板卡的加载所需时长仍有进一步压缩的空间，通过并行多线程的方式来处理加载过程，这是后续优化完善的方向。本文所提出的基于软件中间件的编 码板兼容性思路，可以应用于同类其他软、硬件部件级替代的兼容性设计中。