基于DirectFB的嵌入式播放器設(shè)計-設(shè)計應(yīng)用

精品文檔-下載后可編輯基于DirectFB的嵌入式播放器設(shè)計-設(shè)計應(yīng)用摘要：隨著嵌入式設(shè)備應(yīng)用越來越普及，其對圖形處理功能提出了更高的要求。因此輕量、高效的基于Framebuffer的DirectFB庫的實現(xiàn)方案受到越來越多的嵌入式工程師的青睞。本文首先對DirectFB進行了介紹，接著提出了一種新的基于DirectFB的嵌入式播放器設(shè)計方案。該方案相比于其他嵌入式GUI開發(fā)的播放器能夠有效地降低資源的消耗，適用于各種中低端的場合，同時具備良好的可移植性。

1概述

隨著嵌入式的普及和發(fā)展，嵌入式設(shè)備的功能越來越強大，用戶對嵌入式設(shè)備的要求也越來越高。各種多媒體應(yīng)用程序被移植到了嵌入式系統(tǒng)中，是否能夠播放音視頻是人們衡量和購買嵌入式設(shè)備的基本要求之一。本文提出了一種基于DirectFB嵌入式播放器解決方案，有效地降低嵌入式系統(tǒng)的資源消耗，適用于CPU頻率小于400MHz的中低端嵌入式系統(tǒng)。DirectFB是一個輕量級的GUI開發(fā)庫，它通過Framebuffer以及回調(diào)函數(shù)，實現(xiàn)了對硬件設(shè)備的完全抽象，加速和簡化了圖形操作。

本文首先對DirectFB進行了詳細的介紹，接著提出了一種寬松的、可分解的嵌入式播放器設(shè)計方案。該方案資源消耗少、可移植性強、系統(tǒng)各個模塊間依賴度小，使得用戶能夠根據(jù)自己的系統(tǒng)需求快速設(shè)計滿足自己要求的播放器。

2DirectFB簡介

2.1DirectFB的整體框架

DirectFB必須通過Linux下Framebuffer驅(qū)動來訪問硬件設(shè)備，它在Framebuffer的基礎(chǔ)上提供了圖形設(shè)備的加速、輸入設(shè)備處理提取、透明窗口和多重顯示層的功能。另外DirectFB設(shè)計之初就充分考慮了嵌入式系統(tǒng)的固有特性，體積小巧，資源消耗低。作為嵌入式系統(tǒng)中強大的圖形處理庫，DirectFB成為Linux下一代處理的一個新標準（CELFAVG1.0標準）。圖1是DirectFB的整體框架。

2.2DirectFB接口描述

DirectFB提供了一套C接口來方便用戶進行界面開發(fā)，例如IDirectFBSurface接口提供了對于文本、BILT、畫線以及畫矩形的操作。IDirectFBFont接口提供了對字體的操作，而IDirectFBVideo接口提供了對多媒體進行播放控制的操作。表1對DirectFB接口進行了詳細的描述。

3播放器的框架

嵌入式播放器的架構(gòu)如圖2所示。采用DirectFB開發(fā)的Lite作為圖形界面，與用戶進行直接交互；調(diào)用DirectFB的Video實現(xiàn)了音視頻的插件接口和解碼器模塊。該接口將FFmpeg、xine、libmpeg3等多媒體庫封裝成統(tǒng)一接口，具備很強的擴展性；基于Framebuffer的輸出，消除了對于特定架構(gòu)的依賴，有效地增強了系統(tǒng)的可移植性。

圖形界面是以Lite為基礎(chǔ)開發(fā)的。Lite是基于DirectFB開發(fā)的以box為基類的對話框。通過調(diào)用Lite可以編寫各種暫停、播放、音量等控件，用戶使用這些控件與播放器進行直接交互。DirectFB本身并不提供窗口以及對話框管理功能，因而DirectFB更多地被用作底層圖形庫。參考文獻中選擇以DirectFB為后端的Cairo圖形庫進行2D圖形開發(fā)；參考文獻中選擇基于GTK+onDirectFB進行嵌入式開發(fā)。如今，上層API支持DirectFB的有XDirectFB、DirectFBGL、DFBTerm、DFBSee、DFBPoint、QTonDireelFB、SDL等。采用Lite進行開發(fā)的目的，主要是因為它直接使用DirectFB開發(fā)對話框，而且源代碼只有5MB左右，具有很快的響應(yīng)速度，能夠有效降低嵌入式設(shè)備資源的消耗。

插件接口將對解碼器的操作放到了Video統(tǒng)一的開發(fā)式接口中，該接口實現(xiàn)了分離音視頻、解碼音視頻、播放、暫停、調(diào)節(jié)音量、調(diào)整播放速度等各種功能。通過該接口，播放器的擴展性得到了很大的提高，因此該接口是媒體播放器的。

3.1插件接口以及編解碼

DirectFB通過對FFmpeg進行封裝，形成一組統(tǒng)一接口方便用戶調(diào)用。插件接口通過以下方法來控制解碼器：

①Probe函數(shù)。通過檢查文件擴展名來確定播放器是否支持播放該文件，可以識別的擴展名有wav、au、snd、mp2、mp3、m2a、swf、wma、rm等。用戶可以通過添加新的解碼器來支持更多新的文件格式。

②Construct函數(shù)。通過調(diào)用FFmpeg的一些庫函數(shù)，首先將輸入的視頻文件頭信息讀取出來，接著把視頻文件分離成音頻和視頻流，并申請音頻和視頻流的緩沖區(qū)，然后識別出音視頻解碼器。該函數(shù)同時會將用戶寫的一些非標準函數(shù)指針賦給標準API函數(shù)，方便用戶的調(diào)用。

③FFmpegInput函數(shù)。該函數(shù)管理將對解碼出的音視頻包送入各自的FIFO隊列，同時設(shè)置了一些標志位來管理FIFO隊列，例如音視頻隊列當前的狀態(tài)，當用戶拖動進度條進行偏移時用戶需要有一個拖動標志位，拖動的長度用來重新計算播放時間。

④FFmpegVideo以及FFmpegAudio函數(shù)。這兩個函數(shù)主要用于播放音頻流和數(shù)據(jù)流，同時有一些用于音視頻的同步控制。

⑤FFmpeg_PlayTo函數(shù)。該函數(shù)是給用戶提供的接口函數(shù)，該接口函數(shù)在DirectFB中為PlayTo.在函數(shù)中，PlayTo同時啟動了3個線程，這3個線程分別調(diào)用了FFmpegInpuIt、FFmpegVideo、FFmpegAudio函數(shù)，用于將將音視頻送入FIFO隊列，從FIFO隊列取出數(shù)據(jù)并播放。

播放器的數(shù)據(jù)流程如圖3所示。音視頻處理過程是同步進行的。

此外還有一些控制函數(shù)，例如文件播放PlayTo、播放停止Stop、按時間跳轉(zhuǎn)SeekTo、調(diào)整音量SetVolume、獲取音量GetVolLume、調(diào)整播放速度SetSpeed、獲取播放速度GetSpeed等函數(shù)，這些函數(shù)在construct函數(shù)中被封裝成標準接口便于用戶涮用。

3.2Lite和fusionsound

Video接口通過調(diào)用FFmpeg對音視頻解碼進行了有效的封裝。通過Lite,用戶與播放器實現(xiàn)有效交互。Lite彌補DirectFB在工具箱以及窗口管理上的不足，相比于其他的GUI,它在提供對話框和按鈕的同時，資源消耗較小，適合嵌入式開發(fā)。Fusionsound是一個DirectFB的子庫，它基于oss或者alsa驅(qū)動。Fusionsound將音頻數(shù)據(jù)輸出到了揚聲器上，該函數(shù)庫能夠支持一些基本操作，例如WAV格式文件的播放，同時它也提供一系列的聲音播放、調(diào)節(jié)播放速度、調(diào)高音量、聲音緩沖區(qū)管理等接口。

3.3播放器的流程

程序運行流程如圖4所示。程序首先初始化Lite以及DirectFB庫，然后初始化對話框并設(shè)置回調(diào)函數(shù)；接下來初始化一系列的按鈕，例如播放、暫停、快進、聲音、放大、縮小等，并設(shè)置消息觸發(fā)響應(yīng)函數(shù)。接著調(diào)用DirectFB接口中的video接口播放視頻文件，然后會進入消息循環(huán)，來響應(yīng)用戶各種各樣的按鍵消息。

4實驗結(jié)果

在本實驗中，采用TI公司OMAP-L138處理器、64M的內(nèi)存開發(fā)板做實驗，內(nèi)存占用約為5M左右。通過內(nèi)核設(shè)置，將CPU的主頻設(shè)置為300MHz,播放器在運行期間CPU的占用率為70%,播放畫面十分流暢。DirectFB開發(fā)的播放器如圖5所示。

結(jié)語

DirectFB是一個輕量、高效的庫，但是由于缺少必要的窗口系統(tǒng)導致其開發(fā)效率低。搭配由DirectFB開發(fā)出的Lite窗口系統(tǒng)，能很有效地進行基于對話框的程序開發(fā)。因為Lite和DirectFB本身占用的資源極少，所以十分適合嵌入式開發(fā)。本文提供了一套嵌入式開發(fā)播放器的新思路，通過對編解碼代