随着车辆的普及, 各类汽车电子产品层出不穷, 行车录影作为车载电子领域众多产品中的一项重要功能, 在交通事故责任认定中发挥着不可替代的作用. 众所周知, 车机或是行车记录仪中的录影视频为3–5分钟的分段视频, 数量众多. 在事故发生时, 人们往往需要的是事故发生时间点前后十几秒的视频, 并且应对该视频进行安全备份, 便于检索. 因此, 对视频的抓拍以及处理显得尤为重要. 黄凯奇^[1]等人对智能视频监控技术进行分类, 对目标检测与跟踪、特征提取与分析等经典算法给出了比较全面的综述. 胡博^[2]等人设计了一种对监控视频中的行人进行检测和抓拍的系统. 王崇海^[3]利用多维视频侦查系统检测和抓拍车辆以及人脸, 提取车型、车牌、人脸特征等信息并保存. 吴细老^[4]提出了一种智能交通视频抓拍框架, 对视频图像进行阴影处理与抖动消除, 对违章行为进行判定与抓拍. 高奎贺^[5]提出了采用机动车视频测速进行辅助超速抓拍的技术. 吕正荣^[6]提出了一种对变焦的运动目标进行预测抓拍的方法, 并利用此方法构建了一种交通违法车辆智能跟踪抓拍系统. 目前对视频技术的研究与应用要么立足于利用图像处理与模式识别手段对视频图像进行目标检测、信息提取、恢复、重建等^[7–10]; 要么立足于对视频监控或抓拍系统的设计与开发^[11–14], 而对于视频抓拍本身并没有过多或深入的研究, 涉及到的视频抓拍都是以抓拍时间点为起始时间点, 所拍摄视频包含的信息缺乏完整性, 进而会影响进一步的分析与处理. 由此, 引出一个问题: 当抓拍条件触发时, 能否以抓拍时间点为基准, 保存其之前到之后一定时间段内的视频, 研究目的就是以此展开的.

在众多的智能操作系统中, Android^[15,16]系统以其开放性, 支持硬件多样性, 强大的SDK等优势, 迅速成为视频监控、车载电子、移动终端设备中的主流系统. 首先通过定义时间窗口并利用缓存技术, 阐述抓拍的基本原理, 然后简要介绍一下Android系统中音视频子系统框架, 接着提出一种基于Android系统的视频抓拍方案的设计与实现, 最终给出测试分析以及应用场景.

抓拍所要达到的目标为: 当有事件触发抓拍时, 将当前时间点前M秒到后N秒的音视频数据写入文件, 其中M和N为设定好的预期时间. 其基本思路为: 预设一个时间窗口M+N, 假设当前时间点为时间0点, 对时间段–(M+N)到0之间的音视频数据进行缓存, 如图1所示. 当触发抓拍时, 创建抓拍文件, 等待N秒, 从缓存中取出–M到N秒时间段内的音视频数据, 对其进行封装并写入文件, 如图2所示.

图 1

Fig. 1

图 1 时间窗口

图 2

Fig. 2

图 2 触发抓拍N秒后的时间窗口

抓拍方案基于Android原生系统实现, 所以在阐述抓拍方案之前, 有必要先对Android的音视频子系统框架以及其录制过程做一简单介绍.

Android的音视频子系统(录制部分)如图3所示. 摄像头服务(CameraService)和音频核心服务(AudioFlinger)通过硬件抽象层(HAL)从摄像头驱动(Camera Driver)、音频驱动(Audio Driver)中采集音视频数据. 视频录制的核心服务(MediaPlayerService)负责音视频数据的编码以及封装. 其中, 录制组件(StagefrightRecorder)根据设定的媒体格式类型(MP4、3GP、…)创建组合器(Writer), 视频编码器(VideoEncoder)以及音频编码器(AudioEncoder) 通过共享内存(Shared Memory)从CameraService和AudioFlinger服务中获取音视频数据并进行编码, Writer将编码后的音视频数据封装成设定的媒体格式, 并将其写入文件. 应用程序(Applications)调用框架层(Framework)的媒体录制组件(MediaRecorder)通过Java本地接口(JNI)与库层(Libraries)的MediaRecorder组件进行交互. Libraries层的MediaRecorder通过Android独有的绑定(Binder)机制与MediaPlayerService服务进行进程间通信(IPC).

图 3

Fig. 3

图 3 Android音视频子系统框架(录制部分)

编码后的音视频数据的处理以及封装由组合器完成, 其内部包含两种线程, 一种是获取并处理编码后的音视频数据的轨迹线程, 一种是负责将处理后的音视频数据按照预先设定好的媒体格式封装并写入文件的写线程. 轨迹线程一般有两个, 分别对应音频数据和视频数据, 写线程只有一个, 负责对处理后的音视频数据进行封装并写入文件.

以录制MP4文件为例, 对音视频数据的处理和封装过程如图4虚线上半部分所示. 轨迹线程以帧为单位获取编码后的音视频数据, 每帧数据会先进入一个缓存队列(FIFO, 队列个数与轨迹线程个数相同), 当帧的数量达到一定值时, 轨迹线程会将这些数据帧打包成固定的数据结构(Chunk), 并通知写线程有新的Chunk已准备好. 同时, 轨迹线程将数据帧中的信息及系统环境信息提取汇总存储在一个被称为track的表中, 其包含的信息有Chunk写入文件的偏移地址stco(sample to chunk offset)、Sample与Chunk的映射关系stsc (sample to chunk box)、关键帧stss (sync sample box), 每一帧的持续时间stts (time to sample box)等. 当录制开始时, 写线程创建文件并封装文件头ftyp (file type box)字段, 当写线程接收到Chunk已准备好的通知后搜索缓存队列, 将对应的Chunk写入文件, 并将文件的偏移地址更新到相应track表的stco项(track表中其它数据是由轨迹线程维护). 当录像结束时, track表会被写入到文件尾moov (movie box)字段.

图 4

Fig. 4

图 4 音视频数据的处理与封装过程

抓拍方案的核心思路为: 为音频和视频分别建立音频缓存队列和视频缓存队列, 并创建一个缓存线程, 按照时间从音频轨迹线程和视频轨迹线程中获取打包后的音视频数据, 同时缓存–(N+M)~0秒的音视频数据, 并实时更新缓存数据的track表. 当有抓拍请求到来时, 创建并执行抓拍写线程, 创建文件并封装文件头ftyp字段, 以抓拍时间点为时间0点, 根据预先设定好的M和N(见图2)将从–M秒开始的缓存数据写入文件, 执行N秒后, 抓拍过程结束, 将缓存的音视频数据的track表写入文件尾moov字段, 过程如图4虚线下半部分所示. 抓拍流程如图5所示.

该方案实现于Android系统核心服务MediaPlayerService中的StagefrightRecorder组件和Writer组件中, 并为MediaRecorder提供了抓拍接口, 以便对人机接口(HMI)支持.

图 5

Fig. 5

图 5 抓拍流程图

为了测试抓拍的时间精度以及对系统性能的影响, 将其移植进Android系统中, 硬件配置为主芯片: MTK6735, 4 core, 1.3 G; CPU: ARM Cortex-A53; 内存: 2 GB; 摄像头分辨率: 1280×800. 该方案实现所在进程为Android媒体服务(mediaserver)进程, 设置M、N为不同值(M, N>=5;M+N<20), 多次测试抓拍时长, mediaserver进程的CPU占用率以及内存使用情况, 取平均值, 结果如表1所示(第一行为无抓拍方案的CPU占用率与内存使用情况).

实验结果表明, 抓拍时长与预期时长相比误差范围在500 ms以内; CPU占用率与无抓拍相比, 增加范围在6%以下, 不同预期时长下CPU占用率变化可以忽略不计; 对内存的占用根据预期时长趋于线性变化, 时长每增加1 s, 内存占用增加约1 MB.

抓拍的触发条件可以为车辆发生碰撞或是用户通过HMI手动触发等, 抓拍方案在车联网系统中的应用场景如图6所示.

通过定义时间窗口并利用缓存技术, 提出了一种基于Android系统的视频抓拍方案的设计与实现, 并将其应用于车载电子系统中. 从测试结果可以看出, 该方案具有较小的抓拍时间误差, 引起的CPU占用率变化几乎可以忽略不计, 并且在高清摄像头(1280×800)下, 对内存的影响随抓拍时长呈线性变化, 并且在可接受的范围内. 该方案已被集成进量产并投入市场的Android智能轻车机中, 从用户反馈来看, 该方案所实现的功能能够提供抓拍时间点之前一定时间段内的视频, 及时有效, 在事故认定过程中发挥了关键作用. 抓拍方案基于Android系统实现, 应用于车载电子系统中, 但并不局限于此, 可以应用于任何有此类需要的智能视频监控系统当中.

表 1(Table 1)

表 1 预设不同时间下的抓拍测试结果 M(s) N(s) 抓拍视频长度(s) CPU(%) 内存(KB) - - - 16 29 884 5 5 10.334 21 39 376 5 6 11.462 21 40 328 5 7 12.264 21 41 272 5 8 13.372 20 42 224 5 9 14.466 20 43 172 5 10 15.246 20 44 120 6 5 11.520 20 40 416 6 6 12.368 20 41 188 6 7 13.574 19 42 172 6 8 14.620 22 43 268 6 9 15.376 22 44 032 6 10 16.558 21 45 072 7 5 12.486 20 41 376 7 6 13.548 20 42 332 7 7 14.384 19 43 376 7 8 15.439 19 44 052 7 9 16.436 21 45 128 7 10 17.448 20 46 224 8 5 13.342 19 42 280 8 6 14.554 22 43 448 8 7 15.444 21 44 040 8 8 16.488 22 45 244 8 9 17.366 22 46 356 8 10 18.388 22 47 280 9 5 14.388 20 43 588 9 6 15.446 19 44 320 9 7 16.328 22 45 160 9 8 17.426 21 46 284 9 9 18.484 20 47 184 9 10 19.428 21 48 280 10 5 15.488 22 44 280 10 6 16.364 22 45 392 10 7 17.386 19 46 192 10 8 18.484 21 47 240 10 9 19.368 21 48 488 10 10 20.444 22 49 440

表 1 预设不同时间下的抓拍测试结果

图 6

Fig. 6

图 6 抓拍方案在车联网系统中的应用