車載電子系統(tǒng)中的視頻抓拍技術(shù)①

張文興，孫慶鵬

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

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

抓拍所要達到的目標(biāo)為：當(dāng)有事件觸發(fā)抓拍時，將當(dāng)前時間點前M秒到后N秒的音視頻數(shù)據(jù)寫入文件，其中M和N為設(shè)定好的預(yù)期時間.其基本思路為：預(yù)設(shè)一個時間窗口M+N，假設(shè)當(dāng)前時間點為時間0 點，對時間段-(M+N)到0 之間的音視頻數(shù)據(jù)進行緩存，如圖1所示.當(dāng)觸發(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)負(fù)責(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ù)的軌跡線程，一種是負(fù)責(zé)將處理后的音視頻數(shù)據(jù)按照預(yù)先設(shè)定好的媒體格式封裝并寫入文件的寫線程.軌跡線程一般有兩個，分別對應(yīng)音頻數(shù)據(jù)和視頻數(shù)據(jù)，寫線程只有一個，負(fù)責(zé)對處理后的音視頻數(shù)據(jù)進行封裝并寫入文件.

以錄制MP4 文件為例，對音視頻數(shù)據(jù)的處理和封裝過程如圖4虛線上半部分所示.軌跡線程以幀為單位獲取編碼后的音視頻數(shù)據(jù)，每幀數(shù)據(jù)會先進入一個緩存隊列(FIFO，隊列個數(shù)與軌跡線程個數(shù)相同)，當(dāng)幀的數(shù)量達到一定值時，軌跡線程會將這些數(shù)據(jù)幀打包成固定的數(shù)據(jù)結(jié)構(gòu)(Chunk)，并通知寫線程有新的Chunk 已準(zhǔn)備好.同時，軌跡線程將數(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)等.當(dāng)錄制開始時，寫線程創(chuàng)建文件并封裝文件頭ftyp (file type box)字段，當(dāng)寫線程接收到Chunk 已準(zhǔn)備好的通知后搜索緩存隊列，將對應(yīng)的Chunk 寫入文件，并將文件的偏移地址更新到相應(yīng)track 表的stco 項(track 表中其它數(shù)據(jù)是由軌跡線程維護).當(dāng)錄像結(jié)束時，track表會被寫入到文件尾moov (movie box)字段.

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

抓拍方案的核心思路為：為音頻和視頻分別建立音頻緩存隊列和視頻緩存隊列，并創(chuàng)建一個緩存線程，按照時間從音頻軌跡線程和視頻軌跡線程中獲取打包后的音視頻數(shù)據(jù)，同時緩存-(N+M)～0 秒的音視頻數(shù)據(jù)，并實時更新緩存數(shù)據(jù)的track 表.當(dāng)有抓拍請求到來時，創(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)的視頻，及時有效，在事故認(rèn)定過程中發(fā)揮了關(guān)鍵作用.抓拍方案基于Android 系統(tǒng)實現(xiàn)，應(yīng)用于車載電子系統(tǒng)中，但并不局限于此，可以應(yīng)用于任何有此類需要的智能視頻監(jiān)控系統(tǒng)當(dāng)中.

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

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