劉 勇

（作者單位：安徽廣播電視臺）

基于IMX6嵌入式處理器的音頻流媒體服務器的設計與實現(xiàn)

劉 勇

（作者單位：安徽廣播電視臺）

為了解決智能廣播發(fā)射監(jiān)控系統(tǒng)中廣播信號采集并實時回傳問題，本文提出了一種基于IMX6嵌入式處理器的流媒體服務器的解決方案。筆者深入研究了流媒體技術以及傳輸控制協(xié)議，詳細分析了流媒體技術，并為本文的設計方案制定了最為先進的流媒體傳輸策略。本文整合了多種技術模塊：音頻采集、音頻壓縮、網(wǎng)絡傳輸，實現(xiàn)了一個完整的音頻流媒體采集、壓縮到傳輸?shù)逆溌?。值得注意的是，在音頻壓縮方面，本文采用先進的AAC音頻壓縮技術，而在網(wǎng)絡傳輸方面，本文實現(xiàn)了單播和組播兩種傳輸方式。

嵌入式；IMX6；流媒體；組播

廣播發(fā)射監(jiān)測技術是廣播事業(yè)發(fā)展過程中的熱點技術，是提高工作效率和工作質(zhì)量的重要技術。。智能廣播發(fā)射監(jiān)控系統(tǒng)需要具有以下功能：廣播信號采集并實時回傳功能、廣播發(fā)射狀態(tài)監(jiān)測功能、環(huán)境監(jiān)測功能、供電遠程控制功能與有線無線網(wǎng)絡自動接入功能。這其中廣播信號采集并實時回傳功能是最重要的，而這一功能的實現(xiàn)依賴于先進的流媒體傳輸技術和先進的嵌入式技術。本文設計并實現(xiàn)了一種基于IMX6嵌入式處理器的音頻流媒體解決方案，有效地解決了廣播信號采集并實時回傳的難題。

1　關鍵理論研究

1.1流媒體

流媒體［1］技術的定義是：將音頻、視頻或者其他多媒體文件通過流式傳輸?shù)姆椒ㄔ诰W(wǎng)絡上播放。［2］不同于早先的先下載后播放的模式，通過流媒體技術播放多媒體文件并不需要預先下載媒體數(shù)據(jù)，只需要在播放開始時將少量的數(shù)據(jù)存入緩存區(qū)。

流媒體傳輸?shù)奶卣魇蔷W(wǎng)絡數(shù)據(jù)量大，其特定的傳輸方式：流式傳輸，對傳輸?shù)膶崟r性要求較高，因此與傳統(tǒng)的網(wǎng)絡傳輸相比，通過Internet網(wǎng)絡傳輸流媒體數(shù)據(jù)具有以下特點：①流式傳輸?shù)膶崿F(xiàn)需要一定的緩存空間；②在流式傳輸之前，多媒體文件必須經(jīng)過預處理；③多媒體文件通過流式傳輸需要適當?shù)膫鬏敽涂刂茀f(xié)議。

1.2RTP/RTCP協(xié)議

RTP（Real-time Transport Protocol）實時傳輸協(xié)議是一種專門的網(wǎng)絡傳輸協(xié)議。［3］RTP傳輸協(xié)議是建立在UDP協(xié)議的基礎之上的，只能提供端到端的數(shù)據(jù)傳輸，沒有提供相應的傳輸質(zhì)量保障機制。RTP協(xié)議是一種應用層協(xié)議，在發(fā)送RTP數(shù)據(jù)包之前需要先通過軟件編程對媒體文件數(shù)據(jù)包進行分組和RTP打包，然后將打包后的RTP數(shù)據(jù)發(fā)送給UDP接口，添加UDP傳輸信息和IP數(shù)據(jù)包頭，再通過Internet發(fā)送至接收端。

實時運輸控制協(xié)議RTCP（RTP Control Protocol）是RTP協(xié)議實際使用過程中不可或缺的一部分。［4］RTCP協(xié)議主要是在RFC3550和RFC3551中做出了解釋［5］［6］。

RTCP協(xié)議的主要功能是：為RTP傳輸服務質(zhì)量提供監(jiān)視與反饋機制，對多媒體數(shù)據(jù)中不同的媒體流進行同步保證，還可以對多播組中的成員進行標識加以區(qū)分。RTCP協(xié)議同樣是UDP協(xié)議的子協(xié)議，RTCP分組主要是攜帶發(fā)送端和接收端對傳輸質(zhì)量的統(tǒng)計信息報告。

1.3MPEG-4 AAC音頻壓縮標準

AAC編碼算法設計了大量算法模塊，使用戶可以根據(jù)編碼質(zhì)量和實際應用的要求，使用不同模塊組合成復雜度不同的AAC編碼算法。其中，MPEG-4定義了三種不同復雜度的音頻編碼框架類型［7］。

（1）主配置框架（Main Profile）：此框架包括了除增益控制模塊外的所有模塊，其運算復雜度和系統(tǒng)資源的消耗是最高的，但與此同時此種框架也可以提供最好的音質(zhì)。

（2）低復雜度框架（Low Complexity Profile）：此種算法框架擁有較高的適用性和性價比，比較適用于商業(yè)用途，如今最流行的Apple的iTunes音樂庫就使用了此種編碼框架。

（3）可變采樣率框架（Scalable Sampling Rate Profile）：算法復雜度隨著帶寬的變化而變化，并取消了預測模塊，適用于網(wǎng)絡帶寬變換較大的應用場合。

2　嵌入式音頻流媒體服務器的實現(xiàn)

本課題的總體設計方案是采用基于IMX6Q處理器的ARM嵌入式開發(fā)平臺，設計并且實現(xiàn)嵌入式音頻流媒體服務器的軟件應用程序。服務器系統(tǒng)分為3個模塊：原始音頻信號采集模塊、音頻壓縮編碼模塊、傳輸發(fā)送模塊。

2.1原始音頻信號采集模塊設計

在本系統(tǒng)中，將FM解調(diào)信號作為音頻輸入。聲卡則根據(jù)用戶設置參數(shù)對模擬音頻進行數(shù)字采樣，在量化之后便形成了原始音頻數(shù)據(jù)PCM流。對音頻采集的控制。ALSA中的Libasound庫提供了最高級且方便的編程接口。

數(shù)據(jù)采集函數(shù)：

snd_pcm_mmap_readi （snd_pcm_ t *pcm， void *buffer， snd_pcm_uframes_t size）

此函數(shù)具體實現(xiàn)了從聲卡中采集數(shù)據(jù)的任務，音頻數(shù)據(jù)采集以size為一個周期，采集數(shù)據(jù)存入緩沖區(qū)buffer，其中size=n*frames，根據(jù)MPEG編碼標準，MPEG-1 layer3的音頻壓縮每幀frames為1 152個樣點，而MPEG-4 AAC的音頻壓縮每幀frames為1 024個樣點。待一個采集周期結(jié)束后，調(diào)用fwrite（）函數(shù)將buffer里的數(shù)據(jù)寫入管道緩沖區(qū)，等待下一模塊的接收。在音頻采集模塊程序設計中，預留了兩個參數(shù)設置接口，分別為采樣時間和采樣頻率。

2.2音頻壓縮編碼模塊設計

在此模塊中，采用MP3以及AAC音頻編碼技術，以滿足各種現(xiàn)實需求。MP3編碼技術得益于它的高壓縮率和高保真度，已經(jīng)被廣泛應用于各種場合。AAC是一種獨立開發(fā)的音頻編碼技術，所以并不與MP3等早期音頻編碼技術相兼容。當AAC音頻的壓縮碼率達到96 kbps時，它便可以達到CD的音質(zhì)，并且還支持5聲道編碼，比MP3更加適合于低碼率傳輸。理論上，同樣音質(zhì)的AAC音頻傳輸時的帶寬占用量相較于MP3會降低1/4。為了實現(xiàn)多種音頻壓縮模式，并且簡化代碼編寫，本文使用添加了Libmp3lame依賴庫和Faac依賴庫的FFMPEG庫。

2.3傳輸發(fā)送模塊設計

使用Jrtplib實現(xiàn)RTP傳輸主要有以下流程。

（1）創(chuàng)建一個RTP傳輸?shù)膶嵗?，以MyRTPSession sess為例，sess為此傳輸實例的名稱。

（2）調(diào)用RTPTransmissionParams類提供的SetPort base接口設置RTP會話要使用的本地端口號；調(diào)用RTPSessionParams類提供的SetOwnTimestampUnit接口設置時戳單元。時間戳單元的設置關系到之后時間戳增量的設置，如果設置的不恰當則會影響接收端的播放質(zhì)量。時戳單元需要根據(jù)所要傳輸?shù)拿襟w數(shù)據(jù)類型來確定，與媒體數(shù)據(jù)的時鐘頻率有關。根據(jù)標準規(guī)定，MPA數(shù)據(jù)類型的時鐘頻率為90000 Hz，則時戳單元就應該被設置為1/90 000。同時還需要調(diào)用SetAcceptOwnPackets接口，將其設置為true，使RTP會話被允許接受私人定義的數(shù)據(jù)類型。

（3）RTP會話創(chuàng)建成功后便可以開始RTP包的傳輸。首先需要調(diào)用RTPSession類提供的AddDestination（）接口添加目的端口及其IP地址，同一個會話中允許添加多個目的端口。待準備工作完成后，就可以通過RTPSession類定義創(chuàng)建的SendPacket（）接口發(fā)送RTP數(shù)據(jù)包了。SendPacket（）是一個重載函數(shù)，有很多調(diào)用方法，其中最常用的一種是：SendPacket（const void *data，size_t len，uint8_ t pt，bool mark，uint32_t timestampinc）。

其中，data指針指向?qū)⒁话l(fā)送的RTP包，len表示此RTP包的數(shù)據(jù)長度，pt為RTP負載類型的有效負載號。mark為標志位，取值為0或1，可以使用此標志位判斷一幀的開始或結(jié)束。

針對不同格式的壓縮音頻數(shù)據(jù)，需要對傳輸時的參數(shù)進行修改，在傳輸MP3音頻數(shù)據(jù)時，需要對負載類型加以定義并設置相關的參數(shù)。參照RFC1890標準的定義，應該選用的負載類型為MPA，有效負載號為14，時鐘頻率則為90 000 Hz，相應的時戳單元則需要設置為1/90 000，計算時間戳增量（以采樣率為48 kHz為例）：

時間戳增量=（1152/48000）*（1/90000）=2160

所以參照標準，傳輸MP3音頻數(shù)據(jù)的發(fā)送函數(shù)為：

status = sess.SendPacket（buff，pksize，14，true，2160）；

相比于MP3音頻的傳輸，傳輸AAC壓縮音頻數(shù)據(jù)則要復雜很多，在RFC協(xié)議中并沒有對AAC格式音頻定義負載類型，所以再次需要自己定義。參照RFC1890標準，有效負載號段96—127為動態(tài)號段，及用戶可以根據(jù)自身需求進行定義，在此將AAC的有效負載號定義為97，時鐘頻率設為90 000 Hz，相對應的時戳單元就等于1/90 000，時間戳增量的計算公式為：

時間戳增量=（1024/48000）*（1/90 000）=1920

AAC格式音頻的發(fā)送函數(shù)為：

status= sess.SendPacket（buff，pksize，14，t rue，1920）

此時雖然數(shù)據(jù)的發(fā)送函數(shù)已經(jīng)設計完畢，但是目前從音頻壓縮模塊傳輸過來的AAC音頻是ADTS格式并不能直接進行RTP傳輸，需要將此種格式的AAC音頻轉(zhuǎn)化為可供RTP傳輸?shù)奶厥飧袷?。此步驟分為兩步，第一步，去除原AAC音頻的7字節(jié)長的ADTS頭，得到純音頻壓縮流。第二步，添加AU頭，共4字節(jié)，分為AU_HEADER_LENGTH和AU_ HEADER。程序?qū)崿F(xiàn)如下。

此段程序中，AU_HEADER_LENGTH設置為16，及AU_HEADER的長度為2個字節(jié)。AU_HEADER的前13個比特為AAC負載長度。

由于在RTP傳輸會話中，AAC的負載類型是自己定義的，第三方軟件在接收時并不能自動識別音頻格式并調(diào)用合適的解碼器，對此需要通過帶外的方式傳遞載有音頻編碼信息的SDP文件給第三方播放器（如VLC）。SDP文件的編寫規(guī)范參照RFC3016、RFC3064標準。［8］［9］

在此，筆者參考各種規(guī)范，定義了用來傳輸AAC媒體流的SDP文件，并且經(jīng)過實際驗證，可以通過VLC播放器打開并實現(xiàn)流媒體接收。

3　音頻流媒體服務器系統(tǒng)性能測試

3.1硬件資源占用率測試

筆者通過Linux的TOP命令查看流媒體系統(tǒng)各個程序模塊的資源占用率情況（此階段，使用MP3格式作為測試格式）。進程PID3930為音頻采集模塊，PID3931為音頻編碼模塊，PID 3932 為傳輸發(fā)送模塊?？梢钥闯?，CPU占用率最高的為音頻編解碼模塊。其中音頻編碼模塊CPU占用率為44%，而其他模塊的CPU占用率都不高于1%。而在內(nèi)存占用率方面，各模塊都不超過0.1%，可見此流媒體系統(tǒng)對硬件內(nèi)存要求不高。

3.2網(wǎng)絡傳輸性能測試

經(jīng)過網(wǎng)絡分析，筆者得到服務器端的數(shù)據(jù)發(fā)送速率，從在20秒內(nèi)，發(fā)送速率一直維持在120Kbps～135Kbps，發(fā)送速率相對穩(wěn)定。

4　結(jié)語

本文采用基于IMX6Q處理器的嵌入式開發(fā)板，設計與實現(xiàn)了嵌入式流媒體服務器。整個系統(tǒng)分為3個模塊，分別是音頻采集模塊、音頻編碼模塊、網(wǎng)絡傳輸發(fā)送模塊。圍繞該系統(tǒng)的設計與實現(xiàn)，本文進行了以下的研究工作。

（1）在音頻編解碼技術上，本文采用了MP3以及AAC兩種音頻編碼技術，可以滿足系統(tǒng)在不同環(huán)境下的傳輸要求。其中對AAC壓縮編碼的支持，是本課題實現(xiàn)的一個亮點。

（2）在流媒體傳輸技術上，本課題不只實現(xiàn)了一對一的網(wǎng)絡傳輸，同時還可以實現(xiàn)組播模式，實現(xiàn)一對多的網(wǎng)絡傳輸，這是本課題實現(xiàn)的另一個亮點。

但是由于時間有限以及本人能力的不足，整個系統(tǒng)還有許多可以完善的地方。

（1）在硬件層面上，雖然IMX6Q是一種相當先進的微處理器，但是由于其他相關硬件的限制，尚不能完全發(fā)揮該處理器的性能。所以在未來的研究中，可以通過自行設計相關技術模塊，使其可以成為專業(yè)的流媒體服務器系統(tǒng)。

（2）在軟件層面上，本文設計的軟件系統(tǒng)總體分為3個模塊，但是在傳輸發(fā)送模塊由于需要添加對多種壓縮格式的支持，需要分別編寫應用程序，調(diào)用比較復雜，所以希望在后續(xù)的研究中，將此模塊進行整合，簡化程序調(diào)用方法。