張文興，孫慶鵬

(沈陽美行科技有限公司，沈陽 110000)

隨著車輛的普及，各類汽車電子產(chǎn)品層出不窮，行車錄影作為車載電子領(lǐng)域眾多產(chǎn)品中的一項重要功能，在交通事故責(zé)任認定中發(fā)揮著不可替代的作用.眾所周知，車機或是行車記錄儀中的錄影視頻為3-5 分鐘的分段視頻，數(shù)量眾多.在事故發(fā)生時，人們往往需要的是事故發(fā)生時間點前后十幾秒的視頻，并且應(yīng)對該視頻進行安全備份，便于檢索.因此，對視頻的抓拍以及處理顯得尤為重要.黃凱奇[1]等人對智能視頻監(jiān)控技術(shù)進行分類，對目標檢測與跟蹤、特征提取與分析等經(jīng)典算法給出了比較全面的綜述.胡博[2]等人設(shè)計了一種對監(jiān)控視頻中的行人進行檢測和抓拍的系統(tǒng).王崇海[3]利用多維視頻偵查系統(tǒng)檢測和抓拍車輛以及人臉，提取車型、車牌、人臉特征等信息并保存.吳細老[4]提出了一種智能交通視頻抓拍框架，對視頻圖像進行陰影處理與抖動消除，對違章行為進行判定與抓拍.高奎賀[5]提出了采用機動車視頻測速進行輔助超速抓拍的技術(shù).呂正榮[6]提出了一種對變焦的運動目標進行預(yù)測抓拍的方法，并利用此方法構(gòu)建了一種交通違法車輛智能跟蹤抓拍系統(tǒng).目前對視頻技術(shù)的研究與應(yīng)用要么立足于利用圖像處理與模式識別手段對視頻圖像進行目標檢測、信息提取、恢復(fù)、重建等[7-10]；要么立足于對視頻監(jiān)控或抓拍系統(tǒng)的設(shè)計與開發(fā)[11-14]，而對于視頻抓拍本身并沒有過多或深入的研究，涉及到的視頻抓拍都是以抓拍時間點為起始時間點，所拍攝視頻包含的信息缺乏完整性，進而會影響進一步的分析與處理.由此，引出一個問題：當抓拍條件觸發(fā)時，能否以抓拍時間點為基準，保存其之前到之后一定時間段內(nèi)的視頻，研究目的就是以此展開的.

在眾多的智能操作系統(tǒng)中，Android[15，16]系統(tǒng)以其開放性，支持硬件多樣性，強大的SDK 等優(yōu)勢，迅速成為視頻監(jiān)控、車載電子、移動終端設(shè)備中的主流系統(tǒng).首先通過定義時間窗口并利用緩存技術(shù)，闡述抓拍的基本原理，然后簡要介紹一下Android 系統(tǒng)中音視頻子系統(tǒng)框架，接著提出一種基于Android 系統(tǒng)的視頻抓拍方案的設(shè)計與實現(xiàn)，最終給出測試分析以及應(yīng)用場景.

1 抓拍原理

抓拍所要達到的目標為：當有事件觸發(fā)抓拍時，將當前時間點前M秒到后N秒的音視頻數(shù)據(jù)寫入文件，其中M和N為設(shè)定好的預(yù)期時間.其基本思路為：預(yù)設(shè)一個時間窗口M+N，假設(shè)當前時間點為時間0 點，對時間段-(M+N)到0 之間的音視頻數(shù)據(jù)進行緩存，如圖1所示.當觸發(fā)抓拍時，創(chuàng)建抓拍文件，等待N秒，從緩存中取出-M到N秒時間段內(nèi)的音視頻數(shù)據(jù)，對其進行封裝并寫入文件，如圖2所示.

圖2 觸發(fā)抓拍N 秒后的時間窗口

2 Android 的音視頻子系統(tǒng)

抓拍方案基于Android 原生系統(tǒng)實現(xiàn)，所以在闡述抓拍方案之前，有必要先對Android 的音視頻子系統(tǒng)框架以及其錄制過程做一簡單介紹.

Android 的音視頻子系統(tǒng)(錄制部分)如圖3所示.攝像頭服務(wù)(CameraService)和音頻核心服務(wù)(Audio Flinger)通過硬件抽象層(HAL)從攝像頭驅(qū)動(Camera Driver)、音頻驅(qū)動(Audio Driver)中采集音視頻數(shù)據(jù).視頻錄制的核心服務(wù)(MediaPlayerService)負責(zé)音視頻數(shù)據(jù)的編碼以及封裝.其中，錄制組件(StagefrightRecorder)根據(jù)設(shè)定的媒體格式類型(MP4、3GP、…)創(chuàng)建組合器(Writer)，視頻編碼器(VideoEncoder)以及音頻編碼器(AudioEncoder) 通過共享內(nèi)存(Shared Memory)從CameraService 和AudioFlinger 服務(wù)中獲取音視頻數(shù)據(jù)并進行編碼，Writer 將編碼后的音視頻數(shù)據(jù)封裝成設(shè)定的媒體格式，并將其寫入文件.應(yīng)用程序(Applications)調(diào)用框架層(Framework)的媒體錄制組件(MediaRecorder)通過Java 本地接口(JNI)與庫層(Libraries)的MediaRecorder組件進行交互.Libraries 層的MediaRecorder 通過Android獨有的綁定(Binder)機制與MediaPlayerService 服務(wù)進行進程間通信(IPC).

圖3 Android 音視頻子系統(tǒng)框架(錄制部分)

3 抓拍方案的設(shè)計與實現(xiàn)

編碼后的音視頻數(shù)據(jù)的處理以及封裝由組合器完成，其內(nèi)部包含兩種線程，一種是獲取并處理編碼后的音視頻數(shù)據(jù)的軌跡線程，一種是負責(zé)將處理后的音視頻數(shù)據(jù)按照預(yù)先設(shè)定好的媒體格式封裝并寫入文件的寫線程.軌跡線程一般有兩個，分別對應(yīng)音頻數(shù)據(jù)和視頻數(shù)據(jù)，寫線程只有一個，負責(zé)對處理后的音視頻數(shù)據(jù)進行封裝并寫入文件.

以錄制MP4 文件為例，對音視頻數(shù)據(jù)的處理和封裝過程如圖4虛線上半部分所示.軌跡線程以幀為單位獲取編碼后的音視頻數(shù)據(jù)，每幀數(shù)據(jù)會先進入一個緩存隊列(FIFO，隊列個數(shù)與軌跡線程個數(shù)相同)，當幀的數(shù)量達到一定值時，軌跡線程會將這些數(shù)據(jù)幀打包成固定的數(shù)據(jù)結(jié)構(gòu)(Chunk)，并通知寫線程有新的Chunk 已準備好.同時，軌跡線程將數(shù)據(jù)幀中的信息及系統(tǒng)環(huán)境信息提取匯總存儲在一個被稱為track 的表中，其包含的信息有Chunk 寫入文件的偏移地址stco(sample to chunk offset)、Sample 與Chunk 的映射關(guān)系stsc (sample to chunk box)、關(guān)鍵幀stss (sync sample box)，每一幀的持續(xù)時間stts (time to sample box)等.當錄制開始時，寫線程創(chuàng)建文件并封裝文件頭ftyp (file type box)字段，當寫線程接收到Chunk 已準備好的通知后搜索緩存隊列，將對應(yīng)的Chunk 寫入文件，并將文件的偏移地址更新到相應(yīng)track 表的stco 項(track 表中其它數(shù)據(jù)是由軌跡線程維護).當錄像結(jié)束時，track表會被寫入到文件尾moov (movie box)字段.

圖4 音視頻數(shù)據(jù)的處理與封裝過程

抓拍方案的核心思路為：為音頻和視頻分別建立音頻緩存隊列和視頻緩存隊列，并創(chuàng)建一個緩存線程，按照時間從音頻軌跡線程和視頻軌跡線程中獲取打包后的音視頻數(shù)據(jù)，同時緩存-(N+M)～0 秒的音視頻數(shù)據(jù)，并實時更新緩存數(shù)據(jù)的track 表.當有抓拍請求到來時，創(chuàng)建并執(zhí)行抓拍寫線程，創(chuàng)建文件并封裝文件頭ftyp字段，以抓拍時間點為時間0 點，根據(jù)預(yù)先設(shè)定好的M和N(見圖2)將從-M秒開始的緩存數(shù)據(jù)寫入文件，執(zhí)行N秒后，抓拍過程結(jié)束，將緩存的音視頻數(shù)據(jù)的track 表寫入文件尾moov 字段，過程如圖4虛線下半部分所示.抓拍流程如圖5所示.

該方案實現(xiàn)于Android 系統(tǒng)核心服務(wù)MediaPlayer Service 中的StagefrightRecorder 組件和Writer 組件中，并為MediaRecorder 提供了抓拍接口，以便對人機接口(HMI)支持.

圖5 抓拍流程圖

4 測試分析與應(yīng)用場景

為了測試抓拍的時間精度以及對系統(tǒng)性能的影響，將其移植進Android 系統(tǒng)中，硬件配置為主芯片：MTK6735，4 core，1.3 G；CPU：ARM Cortex-A53；內(nèi)存：2 GB；攝像頭分辨率：1280×800.該方案實現(xiàn)所在進程為Android 媒體服務(wù)(mediaserver)進程，設(shè)置M、N為不同值(M，N＞=5；M+N＜20)，多次測試抓拍時長，mediaserver進程的CPU 占用率以及內(nèi)存使用情況，取平均值，結(jié)果如表1所示(第一行為無抓拍方案的CPU 占用率與內(nèi)存使用情況).

實驗結(jié)果表明，抓拍時長與預(yù)期時長相比誤差范圍在500 ms 以內(nèi)；CPU 占用率與無抓拍相比，增加范圍在6%以下，不同預(yù)期時長下CPU 占用率變化可以忽略不計；對內(nèi)存的占用根據(jù)預(yù)期時長趨于線性變化，時長每增加1 s，內(nèi)存占用增加約1 MB.

抓拍的觸發(fā)條件可以為車輛發(fā)生碰撞或是用戶通過HMI 手動觸發(fā)等，抓拍方案在車聯(lián)網(wǎng)系統(tǒng)中的應(yīng)用場景如圖6所示.

5 結(jié)論與展望

通過定義時間窗口并利用緩存技術(shù)，提出了一種基于Android 系統(tǒng)的視頻抓拍方案的設(shè)計與實現(xiàn)，并將其應(yīng)用于車載電子系統(tǒng)中.從測試結(jié)果可以看出，該方案具有較小的抓拍時間誤差，引起的CPU 占用率變化幾乎可以忽略不計，并且在高清攝像頭(1280×800)下，對內(nèi)存的影響隨抓拍時長呈線性變化，并且在可接受的范圍內(nèi).該方案已被集成進量產(chǎn)并投入市場的Android 智能輕車機中，從用戶反饋來看，該方案所實現(xiàn)的功能能夠提供抓拍時間點之前一定時間段內(nèi)的視頻，及時有效，在事故認定過程中發(fā)揮了關(guān)鍵作用.抓拍方案基于Android 系統(tǒng)實現(xiàn)，應(yīng)用于車載電子系統(tǒng)中，但并不局限于此，可以應(yīng)用于任何有此類需要的智能視頻監(jiān)控系統(tǒng)當中.

表1 預(yù)設(shè)不同時間下的抓拍測試結(jié)果

圖6 抓拍方案在車聯(lián)網(wǎng)系統(tǒng)中的應(yīng)用