趙 川，伍瑞卿，樊 豐

（電子科技大學(xué) 電子工程學(xué)院，四川 成都 611731）

1 引言

網(wǎng)絡(luò)視頻傳輸?shù)玫搅嗽絹?lái)越廣泛的應(yīng)用，如IP可視電話、數(shù)字?jǐn)z像機(jī)、網(wǎng)絡(luò)視頻會(huì)議、視頻監(jiān)控系統(tǒng)，數(shù)字視頻播放器/點(diǎn)播機(jī)等。在很多應(yīng)用場(chǎng)合，都需要小型的嵌入式系統(tǒng)來(lái)實(shí)現(xiàn)[1]。通常，基于DSP的協(xié)議棧都移植自LWIP，uIP。而這些協(xié)議棧并不針對(duì)視頻傳輸設(shè)計(jì)。視頻傳輸中通常使用UDP協(xié)議以保證傳輸?shù)膶?shí)時(shí)性[2]。但是UDP的傳輸是無(wú)連接的，不可靠的。例如，在H.264中，如果丟掉解碼圖像需要的參數(shù)集或者IDR圖像，會(huì)造成無(wú)法解碼的結(jié)果。筆者提出了一種針對(duì)視頻流傳輸?shù)母倪M(jìn)的UDP協(xié)議，在確保正確解碼的同時(shí)，保證了較小的開銷和較高的效率。

2 TMS320DM642 DSP開發(fā)平臺(tái)

TMS320DM642（簡(jiǎn)稱DM642）是TI公司的一款專用于數(shù)字媒體應(yīng)用的高性能32位定點(diǎn)DSP芯片。工作主頻高達(dá)720 MHz，處理能力可達(dá)5 760 MI/s（兆指令/秒），外部總線時(shí)鐘100MHz。DM642集成了64個(gè)32 bit的通用寄存器，能夠在一個(gè)時(shí)鐘周期內(nèi)處理4個(gè)16 bit的乘法和8個(gè)8 bit的乘法。64 bit寬度的EMIF總線，可連接大容量 SDRAM，F(xiàn)lash，ATA等存儲(chǔ)器資源。4路PAL/NTSC標(biāo)準(zhǔn)模擬視頻輸入，1路PAL/NTSC標(biāo)準(zhǔn)模擬視頻輸出，以及一個(gè)支持10/100 Mbit/s自適應(yīng)網(wǎng)卡的EMAC/MDIO模塊，通過寄存器配置可提供一定的QoS保證[3]。因此，該芯片非常適合視頻數(shù)據(jù)的處理和傳輸。

3 網(wǎng)絡(luò)驅(qū)動(dòng)程序的開發(fā)

網(wǎng)絡(luò)接口控制芯片主要由 EMAC Control，EMAC，MDIO等模塊控制。

3.1 模塊主要功能和結(jié)構(gòu)

MAC Control：主要作為DSP與EMAC/MDIO的接口，提供4 kbyte的本地內(nèi)存空間給EMAC的包緩沖描述符；具有總線仲裁、重啟EMAC/MDIO、全局中斷使能、中斷邏輯控制等功能，與EMAC模塊一起初始化。

MDIO：使用有限狀態(tài)機(jī)配置和監(jiān)控物理層設(shè)備（PHY）。

EMAC：用于在網(wǎng)絡(luò)上發(fā)送和接收數(shù)據(jù)包。而開發(fā)設(shè)備驅(qū)動(dòng)主要是對(duì)該模塊編程。EMAC的特點(diǎn)是：1）作為DMA控制器，在DSP內(nèi)部和外部存儲(chǔ)空間之間傳送數(shù)據(jù)；2）連接PHY的介質(zhì)無(wú)關(guān)接口（MII）；3）8個(gè)接收和8個(gè)發(fā)送通道，提供一定的QoS支持；4）可選的發(fā)送CRC校驗(yàn)；5）支持多播、廣播和混合模式；6）硬件流控制。

模塊框圖如圖1所示，其中EMAC/MDIO通過中斷映射到DSP的11號(hào)中斷，EMAC通過DSP內(nèi)存轉(zhuǎn)換控制器讀寫DSP的內(nèi)部外部存儲(chǔ)空間，模塊的控制寄存器通過DSP配置總線映射到DSP存儲(chǔ)空間。

圖1 模塊結(jié)構(gòu)框圖

3.2 底層驅(qū)動(dòng)的軟件結(jié)構(gòu)

EMAC使用描述符來(lái)管理接收和發(fā)送緩沖隊(duì)列。描述符是一個(gè)16 byte的內(nèi)存結(jié)構(gòu)，存儲(chǔ)在EMACControl模塊中，包含數(shù)據(jù)包的長(zhǎng)度，存放位置等信息[4]。每個(gè)描述符表示1個(gè)以太網(wǎng)包。每次發(fā)送或者接收操作完成，EMAC都會(huì)向DSP發(fā)送中斷，調(diào)整描述符隊(duì)列。

以太網(wǎng)包的接收和發(fā)送是通過一個(gè)緩沖描述符系統(tǒng)實(shí)現(xiàn)的。EMAC提供256個(gè)可用的描述符，每個(gè)接收或發(fā)送通道都有自己的通道描述符結(jié)構(gòu)，用來(lái)維系描述符鏈表。設(shè)備驅(qū)動(dòng)取出空的描述符以便EMAC能夠?qū)⑹盏降囊蕴W(wǎng)包的數(shù)據(jù)寫入對(duì)應(yīng)緩存，將緩存中的即將發(fā)送的數(shù)據(jù)送出并且清理對(duì)應(yīng)的描述符以便重復(fù)利用。

EMAC接收和發(fā)送數(shù)據(jù)的流程如圖2和圖3所示。

圖2 接收流程圖

圖3 發(fā)送流程圖

4 精簡(jiǎn)協(xié)議棧的設(shè)計(jì)與實(shí)現(xiàn)

4.1 協(xié)議層的結(jié)構(gòu)

嵌入式系統(tǒng)中實(shí)現(xiàn)的協(xié)議要根據(jù)各個(gè)系統(tǒng)的特點(diǎn)及功能來(lái)設(shè)計(jì)其獨(dú)特的TCP/IP協(xié)議簇，實(shí)現(xiàn)與需要有關(guān)的部分，而不使用的協(xié)議則省略。在局域網(wǎng)上使用的很多功能，比如路由協(xié)議、SNMP都不需要，只使用ARP，IP，ICMP和UDP，可省略應(yīng)用層協(xié)議。在用于視頻數(shù)據(jù)傳輸?shù)木W(wǎng)絡(luò)中，如果簡(jiǎn)化協(xié)議基于TCP的話，不僅開銷較大，丟失分組將會(huì)造成播放延時(shí)的增大[2]。并且視頻流本身具有一定的錯(cuò)誤恢復(fù)能力，所以本文的協(xié)議棧主要以UDP的發(fā)送和接收為設(shè)計(jì)和測(cè)試對(duì)象。

4.2 存儲(chǔ)緩沖的管理

TCP/IP棧和設(shè)備驅(qū)動(dòng)使用包緩沖區(qū)發(fā)送及接收網(wǎng)絡(luò)包數(shù)據(jù)。在該協(xié)議棧中，開辟32個(gè)包緩沖區(qū)構(gòu)成的緩沖池，而以太網(wǎng)幀長(zhǎng)度限制在1 514 byte或1 518 byte（加入CRC校驗(yàn)），因此設(shè)置每個(gè)緩沖為1 536 byte=（1 024+512） byte，這樣分配可以對(duì)齊Cache邊界，保證沖洗（flush）Cache時(shí)，不會(huì)與其他緩沖區(qū)發(fā)生沖突，并且節(jié)省存儲(chǔ)空間。32個(gè)包緩沖頭使用EMAC的EMAC_Pkt結(jié)構(gòu)。兩段緩沖均存放在片外SDRAM中。協(xié)議棧的數(shù)據(jù)處理和底層設(shè)備接口使用sk_buff的結(jié)構(gòu)，編碼如下：

其中包含1個(gè)底層EMAC的數(shù)據(jù)包指針，這樣就可以方便地將EMAC接收的數(shù)據(jù)包放入?yún)f(xié)議棧的緩沖中。協(xié)議棧中的緩沖skb即是這種結(jié)構(gòu)。

在每次發(fā)送1個(gè)數(shù)據(jù)包之前，都要首先分配skb的存儲(chǔ)空間。從EMAC的空隊(duì)列中彈出1個(gè)EMAC_Pkt的數(shù)據(jù)包，并將skb內(nèi)的這個(gè)數(shù)據(jù)包指針指向它，然后對(duì)skb進(jìn)行操作。在釋放skb時(shí)，將這個(gè)數(shù)據(jù)包壓入空隊(duì)列中以便繼續(xù)使用。

每層協(xié)議在封裝幀頭前，在數(shù)據(jù)區(qū)前預(yù)留這些幀頭的空間，而數(shù)據(jù)區(qū)域不變。這樣數(shù)據(jù)在各層協(xié)議之間傳遞都使用數(shù)據(jù)指針，從而避免了數(shù)據(jù)的重復(fù)搬移，以提高效率。當(dāng)提交到下層協(xié)議時(shí)，將數(shù)據(jù)指針pskb-＞data向前移動(dòng)1個(gè)幀頭長(zhǎng)度。而在接收數(shù)據(jù)時(shí)，每層協(xié)議去掉幀頭，將數(shù)據(jù)指針向后移動(dòng)1個(gè)幀頭長(zhǎng)度。

由于I幀大小一般超過了1 514 byte，需要加入IP分片的功能。首先計(jì)算需要分片數(shù)，預(yù)留該傳輸層需要的幀頭，填入傳輸層的幀頭數(shù)據(jù)，然后從原始數(shù)據(jù)復(fù)制到pskb-＞data，剩下的片預(yù)留IP層需要的幀頭，填入幀頭數(shù)據(jù)后發(fā)送。

ARP的實(shí)現(xiàn)需要建立1個(gè)ARP列表，存放網(wǎng)絡(luò)中主機(jī)（DSP或PC）的ARP信息。在收到1個(gè)IP包后，DSP首先發(fā)送1個(gè)廣播包，查找該報(bào)文中源IP對(duì)應(yīng)的MAC地址，如果不在列表中，發(fā)送ARP請(qǐng)求，在接收到回應(yīng)后，將MAC地址和對(duì)應(yīng)的IP加入列表。

在以太網(wǎng)層，調(diào)用csl中EMAC_sendPacket發(fā)送數(shù)據(jù)。

加入類BSD套接字函數(shù)，封裝底層函數(shù)，包括socket，accept，bind，connect，recv，recvfrom，send，sendto 等， 便于應(yīng)用程序調(diào)用。

5 協(xié)議棧的改進(jìn)

5.1 改進(jìn)的UDP協(xié)議

鑒于參數(shù)集和I幀的重要性，為了提高傳輸?shù)目煽啃?，保證正確接收端正確解碼，并盡量使協(xié)議棧簡(jiǎn)單，采用類似TCP的重傳機(jī)制，流程如圖4所示。

圖4 改進(jìn)的UDP傳輸

閾值 RTO 采用 TCP 的計(jì)算方法[5]：RTO=β×RTT，RTT為平均往返時(shí)延。RTT=α×RTTold+（1-α）×RTTnew，RTTold為上一次的平均往返時(shí)間，RTTnew為新的往返時(shí)間。往返時(shí)間可根據(jù)發(fā)送時(shí)刻的絕對(duì)時(shí)間和接收到接收?qǐng)?bào)告的絕對(duì)時(shí)間來(lái)計(jì)算[5]，每發(fā)送1個(gè)序列（IDR幀更新）就計(jì)算1次。在小型網(wǎng)絡(luò)中，為及時(shí)重傳關(guān)鍵的數(shù)據(jù)包，取α=0.25，β=1.5。為測(cè)試簡(jiǎn)便，由幾次實(shí)驗(yàn)估計(jì)，取RTO的值為50ms。

如果需要更可靠的傳輸，可以在接收端每收到1個(gè)數(shù)據(jù)包就發(fā)送1個(gè)IP數(shù)據(jù)包，內(nèi)容為成功接收標(biāo)志位，用于發(fā)送端判斷是否重傳以及接收端剩余的緩存空間，用于發(fā)送端決定是否延遲一小段時(shí)間，等待接收端清理出足夠的緩存空間再發(fā)送數(shù)據(jù)。

5.2 接收?qǐng)?bào)告的設(shè)計(jì)

視頻流的接收情況需要反饋給發(fā)送端以便客戶端和服務(wù)端的交互，發(fā)送速率需要根據(jù)接收端接收和解碼的速率來(lái)進(jìn)行一些調(diào)整以達(dá)到匹配，還可以使發(fā)送端對(duì)出現(xiàn)的問題進(jìn)行分析和采取一些解決措施。通常的反饋接收?qǐng)?bào)告中設(shè)置固定的時(shí)間間隙發(fā)送接收?qǐng)?bào)告[1]，缺乏靈活性，并且該時(shí)間需要大量實(shí)驗(yàn)來(lái)驗(yàn)證，時(shí)間太短會(huì)導(dǎo)致網(wǎng)絡(luò)流量增大，時(shí)間太長(zhǎng)可能無(wú)法及時(shí)使發(fā)送端獲得網(wǎng)絡(luò)狀況并由此控制發(fā)送端調(diào)整發(fā)送速率。因此設(shè)計(jì)在接收端成功接收到參數(shù)集和I幀后，或者解碼1個(gè)序列（下一個(gè)IDR幀到來(lái)）后，發(fā)送1個(gè)接收?qǐng)?bào)告。發(fā)送端可以根據(jù)接收?qǐng)?bào)告檢測(cè)網(wǎng)絡(luò)狀況及延時(shí)抖動(dòng)，然后相應(yīng)的調(diào)整發(fā)送速率。如果在報(bào)文中加入各幀解碼時(shí)間，還可以調(diào)整編碼的碼率，以達(dá)到編碼和解碼的速率的匹配。

為了提高兼容性和擴(kuò)展性，參照使用RTCP報(bào)文的頭部，以便其他能夠解析RTCP包的應(yīng)用程序識(shí)別。報(bào)頭格式如圖5所示。

圖5 報(bào)文頭格式

圖5中，V為版本號(hào)，用于識(shí)別報(bào)文的合法性。P為填充位，為1時(shí)表示數(shù)據(jù)包末位有填充位。RC為報(bào)告位，數(shù)據(jù)包中所含有的報(bào)告數(shù)目。PT為類型，不同的值代表不同類型的包，可針對(duì)不同的用途設(shè)計(jì)不同內(nèi)容的報(bào)文，以類型區(qū)分。例如，用于視頻監(jiān)控（基本檔次），用于流媒體播放（擴(kuò)展檔次）等。Len為整個(gè)數(shù)據(jù)包的長(zhǎng)度，不包括報(bào)頭長(zhǎng)。每種類型的報(bào)文有固定的長(zhǎng)度，如果不符合可以直接丟棄。報(bào)文內(nèi)容如圖6所示。

圖6中，T n為第n幀的傳輸時(shí)間。n由發(fā)送端的I幀周期決定，或者由接收端設(shè)定。丟包的序號(hào)由接收端根據(jù)發(fā)送的RTP數(shù)據(jù)包內(nèi)容決定。丟包率表示從接收到第一個(gè)數(shù)據(jù)包開始的時(shí)間內(nèi)丟掉的數(shù)據(jù)包總數(shù)與累積接收到的數(shù)據(jù)包的總數(shù)的比例?？刂茦?biāo)志位為0時(shí)，不變；為1時(shí)，提高碼率；為2時(shí)，降低碼率；為3時(shí)，關(guān)掉此連接。

圖6 報(bào)文內(nèi)容

6 測(cè)試結(jié)果

測(cè)試使用網(wǎng)線直連DSP和PC，如果PC網(wǎng)卡沒有自適應(yīng)交叉線/直通線功能，則必須制作交叉線來(lái)進(jìn)行測(cè)試。

在PC（IP地址為192.168.1.20）上使用控制臺(tái)ping配置的DSP的IP地址（192.168.1.10），并且使用wireshark軟件抓取PC網(wǎng)卡上的數(shù)據(jù)包。測(cè)試結(jié)果如圖7所示。

圖7 wireshark測(cè)試結(jié)果

首先，PC網(wǎng)卡向DSP發(fā)送第1個(gè)ping請(qǐng)求，DSP接收到后發(fā)送ARP請(qǐng)求，PC回應(yīng)自己IP對(duì)應(yīng)的網(wǎng)卡地址，DSP回應(yīng)ping請(qǐng)求。表明ARP協(xié)議和ICMP協(xié)議正確實(shí)現(xiàn)。

在實(shí)際視頻序列傳輸中，采用foreman，news的QCIF以及CIF序列測(cè)試，解碼端能夠正確解碼播放，并且達(dá)到設(shè)定的幀率。對(duì)于誤碼重傳仿真測(cè)試，本文不再詳述。

7 小結(jié)

基于DSP的視頻傳輸有著廣闊的應(yīng)用空間，筆者提出了一個(gè)精簡(jiǎn)協(xié)議棧的設(shè)計(jì)和實(shí)現(xiàn)方法，以及與EMAC底層驅(qū)動(dòng)的連接，并針對(duì)H.264視頻流的特點(diǎn)做了一些改進(jìn)。實(shí)驗(yàn)證明，該協(xié)議棧可滿足多種應(yīng)用需求。

[1]王力生，梅巖，曹南洋.輕量級(jí)嵌入式TCP/IP協(xié)議棧的設(shè)計(jì)[J].計(jì)算機(jī)工程，2007，33（2）：246-248.

[2]畢厚杰.新一代視頻壓縮編碼標(biāo)準(zhǔn)——H.264/AVC[M].北京：人民郵電出版社，2005.

[3]Texas Instruments.TMS320C6000 DSP EMAC／MDIO module refer ence guide （Rev.A）[EB/OL].[2009-10-20].http://focus.ti.com/lit/ug/spru628a/spru628a.pdf.

[4]方懷東，陳啟美.基于TMS320DM642的嵌入式TCP/IP協(xié)議棧的實(shí)現(xiàn)[J].電子技術(shù)應(yīng)用，2006，32（9）：25-29.

[5]謝希仁.計(jì)算機(jī)網(wǎng)絡(luò)[M].4版.大連：大連理工大學(xué)出版社，1989.