摘要：根據(jù)視頻監(jiān)控的特點，設計了一種強實時的嵌入式視頻監(jiān)控系統(tǒng)。系統(tǒng)基于QNX(Quick UNIX)嵌入式實時操作系統(tǒng)，采用異構雙核處理器芯片OMAP3530為核心的開發(fā)平臺，實現(xiàn)了視頻的編解碼和傳輸過程。
關鍵詞：QNX；視頻監(jiān)控系統(tǒng)；視頻編解碼；OMAP3530

引言
    嵌入式視頻監(jiān)控系統(tǒng)是當今嵌入式系統(tǒng)發(fā)展的熱門應用，尤其是數(shù)字化視頻監(jiān)控系統(tǒng)越來越受到客戶的青睞。目前，嵌入式視頻監(jiān)控系統(tǒng)大多基于Linux操作系統(tǒng)完成，這對于系統(tǒng)CPU是一個不小的開銷；同時，系統(tǒng)的穩(wěn)定性和實時性無法得到很好的保障。本文提出一種基于QNX系統(tǒng)的視頻監(jiān)控系統(tǒng)。QNX(Quick UNIX)是一種實時的微內核操作系統(tǒng)，有利于減小系統(tǒng)CPU開銷，并提升系統(tǒng)的穩(wěn)定和實時性能；用OMAP 3530處理器中的DSP核來完成視頻的編解碼，有利于提升視頻畫面質量，提高視頻傳輸速率。

1 系統(tǒng)整體設計
    視頻監(jiān)控系統(tǒng)方案是基于開放式多媒體應用平臺OMAP設計的。OMAP3530芯片集成了高性能、低功耗的DSP核與控制性能較好的ARM內核，是一種開放式的、可編程的體系結構。系統(tǒng)ARM端負責初始化整個芯片，包括ARM、DSP、TC(Traffic Controller，流量控制器)等的時鐘設置，DSP的開啟和復位，以及LCD、定時器等各個外設的初始化。DSP端負責視頻的編解碼。監(jiān)控系統(tǒng)硬件結構圖如圖1所示。監(jiān)控系統(tǒng)主要由OMAP3530芯片、USB攝像頭、液晶顯示器、存儲模塊(SDRAM、ROM、Flash)、JTAG構成。USB攝像頭獲取視頻信息后，經(jīng)OMAP3530部進行視頻編解碼處理后，存儲在存儲介質上，或在液晶顯示器上進行顯示。

1．1 OMAP3530平臺介紹
    OMAP3530主要由ARM內核、DSP內核及流量控制器TC組成。
    OMAP3530采用ARM Cortex—A8核，工作主頻最高可達720 MHz。它具有存儲器管理單元、16 KB的高速指令緩沖存儲器、16 KB的數(shù)據(jù)高速緩沖存儲器和256KB的二級Cache；片內有64 KB的內部SRAM，為液晶顯示等應用提供了大量的數(shù)據(jù)和代碼存儲空間。ARM內核擁有整個系統(tǒng)的控制權，可以設置DSP、TC以及各種外設的時鐘及其他工作參數(shù)，控制DSP的運行停止。本設計通過ARM完成對整個視頻監(jiān)控系統(tǒng)的控制和調度。
    DSP內核TMS320C64X+采用3項關鍵的革新技術：增大的空閑省電區(qū)域、變長指令和擴大的并行機制。另外，TMS320C64X+內核增加了固化了算法的硬件加速器，來處理運動估計、8×8的DCT／IDCT和1／2像素插值，降低了視頻處理的功耗。
    流量控制器TC用于控制ARM、DSP以及本地總線對OMAP3530內所有存儲器的訪問。
1．2 雙核之間的通信
    系統(tǒng)的實現(xiàn)，需要讓ARM核與DSP核實現(xiàn)協(xié)調的通信。利用Codee Engine構架，可以實現(xiàn)和管理ARM與DSP雙核之間的數(shù)據(jù)通信。
    Codec Engine是一組用來配置和運行DSP端的符合xDAIS算法的架構，它把符合xDAIS算法納入其架構之下，讓ARM端的QNX可以調用它提供的VISA標準接口，從而實現(xiàn)ARM與DSP的軟件管理。圖2是CodecEngine下一個應用程序的通用構架。

    圖2中，應用程序(Application)或者中間層(mediamiddle ware)調用核心引擎和VISA的API。VISA的API使用存根(Video Encode Stubs)來訪問核心引擎SPI(系統(tǒng)編程接口)和構架(Video Encode Skeleton)。這些構架訪問核心引擎和VISA的SPI。VISA的SPI訪問底層算法。[!--empirenews.page--]
1．3 操作系統(tǒng)介紹
    QNX擁有一個非常高效的徼內核，它負責管理一組同時工作的進程，同時，QNX能夠實現(xiàn)基于消息的進程間通信。這使得QNX具有獨特的高效性、模塊化和簡易化性能。
    整個QNX操作系統(tǒng)是由徼內核調度管理的一組進程的集合，與硬件的總線結構類似，稱之為軟件總線。軟件總線的存在，使得微內核之外的系統(tǒng)模塊能夠像硬件一樣“熱插拔”。在微內核中，應用程序、設備驅動程序、文件系統(tǒng)和網(wǎng)絡協(xié)議棧都駐留在內核外部的獨立地址空間，因此它們與內核以及彼此之間都相互隔離，具有出色的故障包容性：一個組件的故障不會導致整個系統(tǒng)崩潰。提高了系統(tǒng)的穩(wěn)定性和安全性。

    如圖3所示，整個QNX操作系統(tǒng)是由微內核調度管理的一組進程的集合，與硬件的總線結構類似，稱之為軟件總線。軟件總線的存在，使得微內核之外的系統(tǒng)模塊能夠像硬件一樣“熱插拔”。QNX由微內核和一組可供操作的進程構成，具有高度的可裁剪性，最小的配置只占用幾十KB的內存。同時，QNX是一個符合POSIX基本標準和實時標準的操作系統(tǒng)，大大方便了在不同系統(tǒng)之間進行應用程序的移植，這讓許多符合POSIX相應標準的其他系統(tǒng)上開發(fā)的應用程序，不需要修改，在QNX上重新編譯后就能運行。本文將基于Linux操作系統(tǒng)的H．264視頻編解碼程序移植到QNX上，可以節(jié)省大量時間。

2 H．264視頻編解碼
2．1 H．264視頻編解碼基本原理
    H．264采用DCT變化編碼加上DPCM的編碼，即混合編碼結構。同時，H．264在混合編碼的框架下引入了新的編碼方式，提高了編碼效率，更加貼近實際應用。H．264引入了很多先進的技術，包括4×4整數(shù)變換、空域內的幀內預測、1／4像素精度的運動估計、多參考幀與多種大小塊的幀間預測技術等。依賴于算法復雜度的提升，使得壓縮比獲得了極大的提升。
    H．264并未明確地規(guī)定編解碼器如何實現(xiàn)，而是規(guī)定了一個已編碼的視頻比特流的句法和該比特流的解碼方法。
2．2 H．264編解碼器
    (1)編碼部分
    H．264編碼器如圖4所示。輸入的幀或場Fn以宏塊為單位被編碼器按幀內或幀間預測編碼的方法進行處理。如果采用幀問預測編碼，其預測者PRED(圖中P表示)是由當前片中的參考圖像經(jīng)運動補償(MC)后得出，其中參考圖像表示。預測值PRED和當前塊相減后，產(chǎn)生一個殘差塊Dn，經(jīng)塊變換、量化后產(chǎn)生一組量化后的變換系數(shù)X，再經(jīng)熵編碼，與解碼所需的一些信息組成一個壓后的碼流，經(jīng)NAL(網(wǎng)絡自適應層)供傳輸和儲存用。如果采用幀內預測編碼，從圖4可看出，其預測者PRED是由當前片和uFn‘(重建圖像過程中未經(jīng)濾波的幀)的反饋，經(jīng)由幀內預測選擇得出。

    為了提供進一步預測用的參考圖像，編碼器必須具有重建圖像的功能。使殘差圖像經(jīng)反量化、反變化后得到Dn‘，與預測值P相加得到uFn‘。為了提高參考幀的圖像質量以提高壓縮圖像的性能，設置了一個環(huán)路濾波器，濾波后的輸出Fn‘即為重建圖像，可用作參考圖像。
    (2)解碼部分
    H．264解碼器如圖5所示。由編碼器的NAL輸出一個壓縮后的H．264比特流，經(jīng)熵解碼得到量化后的一組變換系數(shù)X，再經(jīng)反量化、反變換，得到殘差的Dn‘。利用從該比特流中解碼出的頭信息，解碼器產(chǎn)生一個預測塊PRED，它和編碼器中的原始PRED相同。當解碼器產(chǎn)生的PRED與殘差Dn‘相加后，就產(chǎn)生uFn‘，再經(jīng)濾波后，最后得到Fn‘，即最后解碼輸出的圖像。

[!--empirenews.page--]
3 系統(tǒng)軟件設計
3．1 視頻處理流程
    視頻處理流程如圖6所示。監(jiān)控系統(tǒng)軟件設計的核心部分是視頻信號的采集、編碼等處理，主要由Capture thread、Video thread、Stream writerthread來實現(xiàn)。Capture thread主要完成采集設備的初始化，使它工作在合適的狀態(tài)，從采集設備獲取原始視頻數(shù)據(jù)放到緩沖區(qū)，為Video thread編碼作準備。Video thread對Capture thread放到緩沖區(qū)中的原始圖像數(shù)據(jù)進行編碼，得到H．264碼流。Stream writer thread的主要工作是把H．264碼流寫入循環(huán)緩沖區(qū)。放在循環(huán)流緩沖區(qū)的碼流可以根據(jù)用戶的需求進行進一步的處理，本系統(tǒng)主要將H．264碼流存儲到SD卡中。

3．2 視頻采集設計
    這里主要介紹系統(tǒng)對于USB接口攝像頭的處理方法，其驅動程序中需要提供I／O操作接口函數(shù)open()、read()、write()、close()，對中斷的處理，內存映射功能以對I／O通道的控制借口函數(shù)ioctl()等，并把他們定義在struct file_operations中。視頻采集系統(tǒng)軟件流程如圖7所示。

    軟件的主要函數(shù)如下：
    Camera_open()：用來開啟視頻設備，使用前需要首先聲明一個camera_device類型的設備文件。
   
   
    camera_get_capability()：通過調用ioctl()函數(shù)取得設備文件的相關信息，并存放到camera_capability結構里。
    camera_get_picture()：通過調用ioctl()函數(shù)取得圖像相關信息，并存放到camera_picture結構里。
    camera_capture()：用來抓取圖像，采用mmap方式，直接將設備文件／dev／videoO映射到內存，加速文件I／O操作，共享內存通信。
    camera_timer：設定一個定時器，用于控制視頻設備采集圖像的時隙。
    picture_save()：保存采集的圖片。
    picture_num()：對保存的圖片計數(shù)，設定一個最大值，每當該計數(shù)器達到最大值時，調用刪除圖片函數(shù)picture_del()，一次性將已發(fā)送的幾張圖片刪除。
    camera_close()：用來關閉視頻設備。

結語
    對于視頻處理來說，采用QNX+OMAP處理器的解決方案是個不錯的選擇。由于視頻編解碼算法實現(xiàn)需要大流量的計算，使用OMAP3530開發(fā)平臺，利用OMAP3530的DSP芯片來完成視頻編解碼，可以較好地提高編解碼的速率；同時，QNX實時操作系統(tǒng)的編程接口符合POSIX標準，可移植性較強，可支持多種視頻格式編解碼。