Linux嵌入式視頻直播監(jiān)控系統(tǒng)

摘要：本文以嵌入式處理器和Linux為開發(fā)平臺，利用嵌入式軟件開發(fā)技術，Linux下圖像采集技術，MPEG-4壓縮技術，RTP傳輸技術，Linux幀緩沖機制等設計并實現(xiàn)了嵌入式視頻直播監(jiān)控系統(tǒng)。
關鍵詞:視頻監(jiān)控，MPEG-4，RTP/RTCP，幀緩沖

Abstract：This paper described how to design and complete an Embedded Video Living Monitoring System, which depended on embedded software developing, Linux graph collection, MPEG-4 compression, RTP translation, Linux framebuffer and use embedded CPU and Linux as developing platform.

Key words: Video Monitoring，MPEG-4，RTP/RTCP，framebuffer

1 引言

近年來，隨著網絡帶寬，計算機處理能力的極大提高和人們安全防范觀念的加強，視頻監(jiān)控領域進入了高速發(fā)展的數(shù)字化的網絡時代。但嵌入式處理器具有低功耗、體積小、經濟、穩(wěn)定的特點；Linux作為一個開源軟件，具有成本低廉的優(yōu)勢，同時兼具安全、穩(wěn)定的特點。因此，以嵌入式處理器作為硬件平臺，以Linux作為軟件平臺的視頻監(jiān)控系統(tǒng)能夠結合兩者的優(yōu)點，必將成為未來的發(fā)展方向。本文介紹了一種Linux嵌入式視頻直播監(jiān)控系統(tǒng)的設計和實現(xiàn)方案。

2 系統(tǒng)概述

圖 1 系統(tǒng)結構圖

系統(tǒng)采用服務器/客戶機架構，分別使用Intel Xscale PXA270、PXA255作為服務器、客戶機硬件平臺，并基于Linux (kernel version：2.6.12)操作系統(tǒng)進行開發(fā)。服務器采集視頻，壓縮后通過局域網傳遞給客戶機；客戶機接收數(shù)據(jù)，解壓縮后播放。

服務器通過USB攝像頭采集YUV格式視頻，然后進行MPEG-4壓縮，將壓縮后的MPEG-4幀進行RTP封裝，并通過RTP協(xié)議進行傳輸?？蛻魴C接收RTP數(shù)據(jù)包，將數(shù)據(jù)組成一幀，然后進行MPEG-4解壓縮，得到YUV格式視頻。然而計算機只能顯示RGB格式視頻，因此通過圖像格式轉換成RGB格式。最后，利用Linux下的幀緩沖機制進行寫屏，從而實現(xiàn)了視頻回放。

3系統(tǒng)軟件設計與實現(xiàn)

3.1V4L視頻采集

Video4Linux(簡稱V4L)是Linux中關于視頻設備的內核驅動，它為針對視頻設備的應用程序編程提供一系列接口函數(shù)，這些視頻設備包括現(xiàn)今市場上流行的TV卡、視頻捕捉卡和USB攝像頭等。對于USB口攝像頭，其驅動程序中需要提供基本的I/O操作接口函數(shù)open，read，write，close的實現(xiàn)、對中斷的處理實現(xiàn)、內存映射功能以及對I/O通道的控制接口函數(shù)ioctl的實現(xiàn)等，并把它們定義在結構體file_operations中。這樣當應用程序對設備文件進行諸如open，close，read，write等系統(tǒng)調用操作時，Linux內核將通過file_operations結構訪問驅動程序提供的函數(shù)。

具體采集工作通過操作ioctl和mmap系統(tǒng)調用進行實現(xiàn)。ioctl實際上是input/output control的縮寫。ioctl系統(tǒng)調用的功能就是通過打開的文件描述符對各種文件尤其是字符設備文件進行控制，完成特定的I/O操作。在本系統(tǒng)中，使用ioctl(fd, VIDIOCGCAP, cap)以獲取攝像頭基本信息；使用ioctl(fd, VIDIOCGMBUF, *mbuf)以獲取攝像頭緩沖區(qū)信息；使用ioctl(fd, VIDIOCMCAPTURE, mm)進行圖像捕捉；使用ioctl(fd, VIDIOCSYNC, frame)等待捕捉完該幀圖像。mmap調用的功能是實現(xiàn)內存映射，即將指定文件或對象的一部分映射到內存中去。這樣可以通過訪問特定的內存區(qū)域來直接對文件或對象進行存取。與read和write。調用相比，這種I/O方式的效率要高得多。

3.2MPEG-4壓縮和解壓縮

MPEG是Moving Pictures Experts Group（運動圖像專家組）的縮寫。MPEG-4由MPEG制定，并于1999年2月正式成為ISO/IEC 14496國際標準。MPEG-4的壓縮方法不同于MPEG1/2或H.263+系列標準，它是基于對象的多媒體數(shù)據(jù)壓縮編碼國際標準，定義的是一種框架、一種格式，而不是一種具體的算法。它在多媒體環(huán)境下提供的基于不同對象的處理方法對自然或合成的音頻、視頻進行壓縮編碼，由一系列支持在該應用領域下的工具組成，能夠針對不同的應用組合使用不同的編碼工具，提供如形狀編碼、運動估計和運動補償編碼、紋理編碼和容錯編碼等技術。

本系統(tǒng)借助于MPEG-4開源庫Xvidcore作為編/解碼庫。具體選用版本1.1.2。Xvidcore中所有的編碼工作都是通過編碼函數(shù)xvid_encore執(zhí)行的，xvide_encore函數(shù)定義如下：

int xvid_encore(void * handle， int opt， void * paraml， void * param2);

其中opt為編碼所要做的操作，opt有以下三種操作：（1）XVID_ENC_CREATE：創(chuàng)建一個新的編碼器，則param1為XVID_ENC_PARAM, handle為新編碼的句柄；（2）XVID_ENC_ENCODE：編碼一幀，則param1為XVID_ENC_FRAME, param2為XVID_ ENC_ STATS或NULL；（3）XVID_DEC_DESTROY：編碼結束，不返回任何句柄。

Xvidcore的所有解碼工作都是由xvid_decore實現(xiàn)的，xvid_decore函數(shù)定義如下：

int xvid_decore(void * handle, int opt, void * param1， void * param2);

其中opt為解碼所要做的操作，opt有以下三種操作：（1）XVID_DEC_CREATE：創(chuàng)建一個新的解碼器,則param1為XVID_DEC_PARAM，handle為新編碼的句柄；（2）XVID_DEC_DECODE: 解碼一幀，則param1為XVID_ENC_FRAME；（3）XVID_DEC_DESTROY: 關掉解碼器，不返回任何句柄。

系統(tǒng)通過采集模塊采集得到YUV420格式的視頻幀存放在緩沖區(qū)中，Xvidcore取出該緩沖區(qū)存放的原始幀數(shù)據(jù)，調用xvid_encore函數(shù)進行編碼。接收端調用xvid_decore函數(shù)對收到的幀進行解碼。從而實現(xiàn)了MPEG-4的壓縮和解壓縮。

3.3RTP傳輸

實時傳輸協(xié)議（Real-time Transport Protocol，RTP）是在 Internet 上處理多媒體數(shù)據(jù)流的一種網絡協(xié)議，利用它能夠在一對一（unicast，單播）或者一對多（multicast，多播）的網絡環(huán)境中實現(xiàn)傳流媒體數(shù)據(jù)的實時傳輸。我們采用開源代碼Jrtplib提供的RTP協(xié)議棧。最新的Jrtplib對RFC3550的實現(xiàn)進行了封裝，使用C++語言開發(fā)，能夠在多種平臺如Linux和Windows下運行。

在網絡帶寬比較低的情況下，數(shù)據(jù)丟幀現(xiàn)象比較嚴重，這對于圖像質量有很大的影響。我們采用拆幀以后再發(fā)送的方法，來降低丟幀率。接收端收到數(shù)據(jù)后，再把屬于同一視頻幀的數(shù)據(jù)組合起來。由于目前常用網絡是802.3的10Mb/s系統(tǒng)，而該系統(tǒng)最大有效載荷為1500字節(jié)，因此設置1400為RTP包大小上限。網絡發(fā)送接收程序流程圖如圖2所示。

圖2 網絡發(fā)送接收程序流程圖

簡單的說，發(fā)送端發(fā)送RTP包到Client端，發(fā)送的時候是分批以數(shù)據(jù)包的形式發(fā)送到Client，就是說發(fā)送一個RTP包需要幾次數(shù)據(jù)包發(fā)送來完成。發(fā)送成功以后發(fā)送下一個數(shù)據(jù)包，通過調用Jrtplib中函數(shù)SendPacket()實現(xiàn)；

接收端依次循環(huán)調用函數(shù)GetNextPacket()來接收某一RTP包的數(shù)據(jù)，數(shù)據(jù)包到來不是按順序到來的，完全接收到RTP包所用的數(shù)據(jù)包以后，根據(jù)時間戳對所接收的數(shù)據(jù)包重新排序重新生成最初的RTP包。接收成功后，調用函數(shù)GotoNextSourceWithData()開始接收下一個RTP包。

3.4寫framebuffer進行播放

framebuffer設備是圖形硬件的抽象概念，意指某些視頻硬件的幀緩沖，使得應用軟件可以通過定義好的接口訪問圖形硬件。framebuffer將顯示的象素點看成是內存的映射，屏幕上每一個點對應framebuffer內存中相應的單元。幀緩沖設備為標準字符設備，主設備號為29，次設備號從0到31，分別對應/dev/fb0-/dev/fb31，默認為/dev/fb0。通過/dev/fb0，應用程序主要完成以下幾種操作：

1. I/O控制（ioctl）操作：對于幀緩沖設備，對設備文件的ioctl操作可讀取(FBIOGET_SCREElVINFO，F(xiàn)BIOGET_SCREElVINFO)和設置(FBIOPUT_VSCREElVINFO， FBIOPUT_FSCREElVINFO)顯示設備及屏幕的參數(shù)，如分辨率、顯示顏色數(shù)、屏幕大小等。

2. 映射(mmap)操作：工作在保護模式的應用程序有自己的虛擬地址空間，但不能直接訪問物理緩沖區(qū)地址，為此可以使用mmap函數(shù)將文件的內容映射到用戶空間。之后用戶就可以通過讀寫這段虛擬地址訪問屏幕緩沖區(qū)在屏幕上繪圖了。

4結束語

本文提出了一種Linux視頻直播監(jiān)控系統(tǒng)的設計和實現(xiàn)方案。經過對系統(tǒng)的測試表明：當客戶端向服務器請求現(xiàn)場音視頻流時，服務器端立刻向通過客戶端發(fā)送音視頻流，客戶端軟件實時接收、實時解碼、實時播放，都能流暢的播放出清晰畫面，無明顯抖動和延時。服務器和客戶機可以穩(wěn)定運行。服務器穩(wěn)定后，CPU利用率達60%-70%，客戶機穩(wěn)定后，CPU利用率達70%-80%。系統(tǒng)穩(wěn)定后，占用帶寬約400kbit/s-500kbit/s，播放幀率約14f/s，能夠滿足一般情況下視頻監(jiān)控要求。

本論文的新見解主要體現(xiàn)在：

（1）提出了一套簡單易行的流媒體直播系統(tǒng)解決方案，并將其應用于嵌入式平臺。

（2）傳輸過程中對RTP數(shù)據(jù)包的大小進行控制，大大降低了丟幀率。

參考文獻:

[1] 陳章龍等. 嵌入式技術與系統(tǒng)――Intel XScale結構與開發(fā). [M]北京 北京航空航天大學出版社，2004

[2] 魯比尼. Linux設備驅動程序(第二版) [M] 北京：電力出版社，2002

[3] 鐘玉琢. 流媒體和視頻服務器. [M] 北京:清華大學出版社.2003. 6

[4] 吳昱軍. 媒體實時傳輸協(xié)議及其在視頻傳輸系統(tǒng)中的運用.微計算機信息.2003.19