基于IMX6嵌入式處理器的音頻流媒體服務(wù)器的設(shè)計(jì)與實(shí)現(xiàn)

劉 勇

（作者單位：安徽廣播電視臺(tái)）

基于IMX6嵌入式處理器的音頻流媒體服務(wù)器的設(shè)計(jì)與實(shí)現(xiàn)

劉 勇

（作者單位：安徽廣播電視臺(tái)）

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

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

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

1　關(guān)鍵理論研究

1.1流媒體

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

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

1.2RTP/RTCP協(xié)議

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

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

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

1.3MPEG-4 AAC音頻壓縮標(biāo)準(zhǔn)

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

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

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

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

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

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

2.1原始音頻信號(hào)采集模塊設(shè)計(jì)

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

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

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

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

2.2音頻壓縮編碼模塊設(shè)計(jì)

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

2.3傳輸發(fā)送模塊設(shè)計(jì)

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

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

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

（3）RTP會(huì)話創(chuàng)建成功后便可以開(kāi)始RTP包的傳輸。首先需要調(diào)用RTPSession類提供的AddDestination（）接口添加目的端口及其IP地址，同一個(gè)會(huì)話中允許添加多個(gè)目的端口。待準(zhǔn)備工作完成后，就可以通過(guò)RTPSession類定義創(chuàng)建的SendPacket（）接口發(fā)送RTP數(shù)據(jù)包了。SendPacket（）是一個(gè)重載函數(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ù)長(zhǎng)度，pt為RTP負(fù)載類型的有效負(fù)載號(hào)。mark為標(biāo)志位，取值為0或1，可以使用此標(biāo)志位判斷一幀的開(kāi)始或結(jié)束。

針對(duì)不同格式的壓縮音頻數(shù)據(jù)，需要對(duì)傳輸時(shí)的參數(shù)進(jìn)行修改，在傳輸MP3音頻數(shù)據(jù)時(shí)，需要對(duì)負(fù)載類型加以定義并設(shè)置相關(guān)的參數(shù)。參照RFC1890標(biāo)準(zhǔn)的定義，應(yīng)該選用的負(fù)載類型為MPA，有效負(fù)載號(hào)為14，時(shí)鐘頻率則為90 000 Hz，相應(yīng)的時(shí)戳單元?jiǎng)t需要設(shè)置為1/90 000，計(jì)算時(shí)間戳增量（以采樣率為48 kHz為例）：

時(shí)間戳增量=（1152/48000）*（1/90000）=2160

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

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

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

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

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

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

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

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

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

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

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

3.1硬件資源占用率測(cè)試

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

3.2網(wǎng)絡(luò)傳輸性能測(cè)試

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

4　結(jié)語(yǔ)

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

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

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

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

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

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