基于Mplayer的嵌入式流媒體播放器的設計與實現*

聞連臣，段曉輝，郭躍超，張 振

（北京大學 無線通信與信號處理研究中心，北京 100871）

0 引言

多媒體的呈現方式從本地播放、下載存儲播放逐步發展到流式播放[1]。流媒體融合了網絡和多媒體編解碼等技術，雖然在PC領域上的應用已比較成熟，但是在嵌入式領域，仍有著很大的開發空間。文中提到的向Mplayer的解碼庫中添加S3C6410的多媒體編解碼模塊MFC(multi format codec)[2]，具有很強的應用價值。

本設計的平臺是HINOC手持測試儀。HINOC[3](High performance Network Over Coax)是“三網融合”中的從光纖網到用戶的一個傳輸方案，如圖1所示。頭端設備(HINOC Brige，HB)對多個終端設備(HINOC Modem，HM)進行管理。

HINOC手持測試儀的主要功能是不僅有 HM的功能，還能協助工程人員進行故障定位。圖2和圖3顯示了其硬件和軟件結構。

工作人員通過流式傳輸可以觀看遠程業務視頻，而且能直觀地驗證網絡的底層是否連通。

1 需求分析

圖1 HINOC網絡結構圖

本系統采用了ARM-Linux，處理器是基于ARM1176-JZF-S的S3C6410，播放器是Linux系統上最優秀的播放器之一 Mplayer[4]，結構如圖 4所示。將S3C6410的MFC加入Mplayer的解碼庫中，通過移植協議棧 live555，Mplayer支持流式傳輸。

圖2 手持測試儀硬件架構

圖3 手持測試儀軟件架構

圖4 Mplayer結構圖

研究發現為Mplayer添加解碼器的方法有多種，總結如表1所示，本文采用了第3個方案。

表1 Mplayer添加解碼器的方法

2 硬件模塊

S3C6410這款16/32位的微處理器，主頻可達667 MHz，主處理器之外集成了MFC，如圖5所示，能支持MPEG4/H.263/H.264/VC1的編解碼，解碼性能可達 720×480 30 f/s或者720×576 25 f/s。S3C6410還支持實時視頻會議等功能。

MFC由BIT和視頻編解碼器組成。BIT處理器對數據流進行分解，一方面與主處理器通信來協調整個流程，另一方面控制視頻解碼器進行解碼。BIT處理器主要包括：BIT處理器內核、程序內存、數據內存、與主處理器進行交互的接口。視頻編解碼器受BIT處理器的控制來完成解碼，內部包含宏塊控制器、預測、塊效應濾波、重構等子模塊。

解碼時需對中間運算緩存，圖5中的外部存儲器提供了這些空間，可分為BIT處理器緩沖和數據緩沖，如圖6和圖7。代碼緩沖區的主要作用是存儲啟動代碼。工作緩存區緩存中間結果，其配合流緩沖區進行工作。參數緩存區主要存幀緩沖的地址。主處理器對流緩沖區進行寫操作，BIT處理器對其進行讀操作，其緩存的是待解碼的數據。幀緩沖區存儲的是解碼后的YUV數據。

圖5 S3C6410中的主處理器和MFC關系圖

圖6 BIT緩沖區存儲結構圖

圖7 數據緩沖區存儲結構圖

3 軟件模塊

3.1 Mplayer結構分析

由圖4知，Mplayer的結構是模塊化的，各個模塊在mplayer.c的協同下工作。下面對其簡要分析。

(1)stream.c所在的輸入層，根據讀入方式來調用文件，正如圖 4中 stream_*.c所示， 如 strean_file.c、stream_ftp.c、stream_netstream.c等。這個過程通過查詢、跳轉、緩存等來完成。

(2)demuxer.c所在的音視頻分流層。demuxer.c是一個基本的框架，對于具體的流如mpeg-es、avi、asf等，都有相應的 demux_*.c。

(3)解碼。解碼器由libmpcodecs/*和分離的庫組成，如liba52、libmpeg2等。Mplayer.c通過dec_audio.c和dec_video.c對流頭sh_audio_t和sh_video_t中的格式進行判斷來選擇解碼器。通過dec_audo.c來調用ad_*.c；通過dec_video.c來調用vd_*.c，即視頻解碼器。解碼之后還需對視頻后期處理，即需用到視頻濾波器vf_*.c。

(4)顯示。video_out.c和 audio_out.c調用不同的顯示模塊，如 vo_directfb.c、vo_fbdev.c等。

3.2 調用MFC的API

應用程序調用MFC的API，現在對其進行介紹，其中涉及了Mplayer中的函數：SsbSipH264DecodeInit():解碼實例的創建，即初始化；SsbSipH264DecodeGetInBuf():獲取輸入緩存區的地址，待解碼數據從這里讀取；

以上函數作為初始化，需要在編寫的vd_*.c中的初始化函數int init(sh_video_t*sh)中調用；

SsbSipH264DecodeGetConfig()：在 vd_*.c 的 mp_image_t*decode(sh_video_t*sh,void*data,int len,int flags)中兩處被調用：其一是為了獲得視頻流的信息，如分辨率的長、寬等，只能在 mp_image_t*decode()第一次執行時調用，否則因時間開銷而影響視頻的顯示，調用的格式為：Ssb-SipH264DecodeGetConfig(handle，H264_DEC_GETCONF_STREAMINFO,&stream_info)；其二獲得輸出地址，格式為：SsbSipH264DecodeGetConfig(handle，H264_DEC_GETCONF_PHYADDR_FRAM_BUF，pYUVBuf)。其源碼結構如下：

SsbSipH264DecodeExe():在函數mp_image_t*decode(sh_video_t*sh,void*data,int len,int flags)中被調用的解碼函數。

SsbSipH264DecodeDeInit():最后對硬件資源的釋放，在 void uninit(sh_video_t*sh)中調用。

4 實現流程

首先，將live555源碼中live中的文件config.armlinux里的CROSS_COMPILE改為CROSS_COMPILE？=arm-linux-；然后依次執行./genMakefile armlinux、make；最后，將編譯好的目錄復制到/usr/local/lib下。其次完成Mplayer軟解碼的移植[5]。

下面介紹如何將MFC添加到Mplayer中，這是本文的關鍵。

首先，在文件etc/codecs.conf中增加解碼器實體。codecs.conf是對音視頻解碼器的聲明，其關鍵字是固定的，如videocodec說明是視頻解碼器。

其次，編寫解碼器vd_mfc264.c。Mplayer定義了一個vd_functions_t型結構體。原型定義在vd.h中，如下所示：

(1)int init(sh_video_t*sh)完成解碼之前的初始化，包括MFC的啟動以及一些API句柄的獲得；

(2)void uninit(sh_video_t*sh)是結束函數，完成解碼后的資源的釋放；

(3)mp_image_t*decode(sh_video_t*sh，void*data，int len,int flags)完成解碼。讀取到的待解碼數據填充到圖7中的流緩沖區，通過與工作緩沖區的交互，將解碼后的YUV數據放入圖7中的幀緩沖區。

Mplayer的視頻解碼器都被libmpcodec目錄下vd.c中的指針數組mpcodecs_vd_drivers所管理,因此增加：

(4)int control(sh_video_t*sh,int cmd,void*arg,...)的作用是控制視頻的解碼和顯示，這個函數是為保障音視頻的同步。

再次，編寫顯示模塊vo_mfcfb.c。S3C6410的MFC可以對解碼后的數據進行縮放、濾波等后期處理。在Mplayer的源碼中，是把數據傳給 video_out.c，然后通過調用vo_fbdev.c來使用framebuffer顯示。在硬解碼中，由于存儲解碼后的數據的物理地址，并不是在處理器的緩存中，而是在外部存儲器中，這導致Mplayer的vo_fbdev.c無法獲得緩存地址。解決辦法就是編寫vo_mfcfb.c，它完成將幀緩存區中的YUV數據進行后期處理并顯示。整個流程如圖4所示。將vo_mfcfb.c加入到video_out.c中，不再具體敘述。

最后，修改 Mplayer下的相關 Makefile，將編寫的兩個源文件和相應的頭文件編譯成靜態鏈接庫。

5 系統測試與分析

現在用一臺PC運行live555來充當流媒體服務器，通過搭建HB，來驗證手持測試儀上的流媒體播放功能。

通過軟件Media Coder將測試視頻轉換成編碼幀率25 f/s、分辨率720×480和不同的編碼碼率的視頻。圖8從播放幀率角度顯示了對比的解碼性能。

圖8 軟硬解碼性能對比

分辨率為720×480、編碼幀率為25 f/s的 H.264視頻,在Arm11平臺下，要想達到人眼視覺可以接受的流暢性，Mplayer的軟解只能達到的碼率為500 kb/s，而使用MFC硬解可以高達3 500 kb/s，比軟解碼提高約3 000 kb/s。

6 結論

流媒體最耗資源的是視頻的解碼，本文利用支持live555的Mplayer的成熟框架，將S3C6410的MFC添加到Mplayer的解碼庫中，不僅可以降低系統對CPU、內存等硬件資源的要求，而且大大提高了視頻質量，這體現了嵌入式應遵循的高性價比理念。而Mplayer在嵌入式領域的應用，通常是對已有軟件解碼器進行算法的優化，或者直接進行移植應用[5]，本文的開發方案為相關應用提供了很好的借鑒。

[1]CONKLIN G J，GREENBAUM G S，LILLEVOLD K O，et al.Video coding for streaming media delivery on the Internet[J].IEEE Transactions on Circuits And Systems for Video Technology，2001，11(3)：269-281.

[2]Samsung Electronics.S3C6410X RISC microprocessor user′s Manual[Z].2008.

[3]國家廣播電影電視總局廣播科學研究院，北京大學，西安電子科技大學，上海明波通信技術股份有限公司，上海未來寬帶技術及應用工程研究中心有限公司.高性能同軸電纜接入技術(HINOC)研究與實現論文集[M].遼寧：遼寧石油化工大學，2011.

[4]Mplayer.The online documentation of Mplayer[EB/OL].(2013-05-01)[2014-06-30].http：//www.mplayerhq.hu/DOCS/HTML/zh_CN/intro.html.

[5]慈文彥，何君，朱明祥.基于ARM處理器的流媒體播放器客戶端的構建[J].信息技術，2012(1)：106-112.