導(dǎo)語(yǔ)：如何才能寫好一篇視頻傳輸，這就需要搜集整理更多的資料和文獻(xiàn)，歡迎閱讀由公務(wù)員之家整理的十篇范文，供你借鑒。

篇1

依據(jù)產(chǎn)品系列的分類，主會(huì)場(chǎng)分為 五個(gè)大區(qū)。

數(shù)字接口系列區(qū)主要展示LIGHTWARE的明星產(chǎn)品EDID管理器，DVI、HDMI信號(hào)放大器等接口設(shè)備。并會(huì)在現(xiàn)場(chǎng)使用一臺(tái)LIGHTWARE MX-8x8-DVI-PRO矩陣搭配Barco Encore系統(tǒng)進(jìn)行聯(lián)動(dòng)演示。

雙絞線延長(zhǎng)器系列區(qū)主要展示LIGHTWARE雙絞線延長(zhǎng)器系列產(chǎn)品，包括最新的采用HDBaseT技術(shù)的TPS系列產(chǎn)品，現(xiàn)場(chǎng)演示了該系列僅使用單根雙絞線傳輸3D/4K視頻信號(hào)。近2年LIGHTWARE接連推出了多款針對(duì)3D、4K信號(hào)的全新產(chǎn)品，由于LIGHTWARE早在2007年的構(gòu)架速率就已經(jīng)達(dá)到12.6Gbit/s，所以在進(jìn)行研發(fā)處理3D、4K信號(hào)設(shè)備的技術(shù)層面上來(lái)說(shuō)，準(zhǔn)備得相當(dāng)充分。

混合模塊化矩陣切換器系列區(qū)展示了一款33輸入/輸出的混合模塊化矩陣，搭配不同的板卡，實(shí)現(xiàn)不同種類信號(hào)的輸入、輸出和快速切換。

光纖延長(zhǎng)器系列區(qū)展示了LIGHTWARE的光纖延長(zhǎng)器產(chǎn)品，有傳統(tǒng)的單芯光纖延長(zhǎng)器，也有當(dāng)前世界獨(dú)有的DisplayPort信號(hào)光纖延長(zhǎng)解決方案并包含KVM功能。

篇2

【關(guān)鍵詞】互聯(lián)網(wǎng)；若干視頻傳輸；關(guān)鍵技術(shù)分析

在網(wǎng)絡(luò)技術(shù)以及多媒體技術(shù)的發(fā)展，面向互聯(lián)網(wǎng)的視頻傳輸無(wú)論是在視頻會(huì)議還是遠(yuǎn)程監(jiān)控中都有了較為廣泛的應(yīng)用，同時(shí)也影響了人們的生活。視頻主要是借助人眼視覺暫留效應(yīng)把靜態(tài)圖像通過一定的速率進(jìn)行播放，進(jìn)而形成了連續(xù)畫面，若是不對(duì)數(shù)字化后的視頻信號(hào)進(jìn)行相關(guān)的壓縮處理，則群無(wú)法進(jìn)行有效傳輸，主要的原因?yàn)槠鋫鬏攷挓o(wú)法滿足傳輸?shù)囊?。怎樣在時(shí)變網(wǎng)絡(luò)服務(wù)質(zhì)量給用戶提供較好的視頻傳輸服務(wù)，依然是目前研究的重要課題，其相關(guān)技術(shù)也是研究重點(diǎn)。

1互聯(lián)網(wǎng)的若干視頻傳輸中存在的問題

當(dāng)前面向互聯(lián)網(wǎng)的視頻傳輸技術(shù)在我國(guó)得到了廣泛的應(yīng)用，然而在移動(dòng)智能設(shè)備、無(wú)線方式接入互聯(lián)網(wǎng)的方式增多，則使網(wǎng)絡(luò)服務(wù)質(zhì)量的不穩(wěn)定性頻發(fā)以及視頻發(fā)送存在問題，因此視頻傳輸?shù)姆€(wěn)定性以及靈活性、普適性有了新的要求。（1）互聯(lián)網(wǎng)的視頻傳輸糾錯(cuò)方法存在問題。在實(shí)際的應(yīng)用中，因?yàn)閬G包率等參數(shù)統(tǒng)計(jì)方法存在一定的時(shí)滯性，造成了FEC的設(shè)計(jì)存在不確定性，優(yōu)化工作難以展開，造成糾錯(cuò)方法穩(wěn)定性不足，進(jìn)而導(dǎo)致接收端的視頻質(zhì)量得不到滿足。然而如何在預(yù)測(cè)丟包率的前提下進(jìn)行合理設(shè)計(jì)，使信道編碼方案的冗余率得以降低，是提高糾錯(cuò)方法的重要環(huán)節(jié)。（2）在擁塞控制下的視頻傳輸技術(shù)。對(duì)于視頻數(shù)據(jù)而言，雖然其能夠容忍丟包率，但是卻對(duì)時(shí)延等QoS參數(shù)變得比較敏感，在互聯(lián)網(wǎng)中，其擁塞控制是由TCP和網(wǎng)絡(luò)設(shè)備（如路由器）所提供的，而在設(shè)計(jì)過程中也沒有考慮到視頻傳輸?shù)奶攸c(diǎn)。（3）對(duì)碼率控制下的視頻傳輸技術(shù)分析。碼率控制可以有效使視頻編碼器的輸出質(zhì)量比較穩(wěn)定，同時(shí)也能夠滿足網(wǎng)絡(luò)服務(wù)質(zhì)量，在當(dāng)前各類視頻編碼標(biāo)準(zhǔn)的碼率控制方法中，即使其將編碼特性的時(shí)空相關(guān)性進(jìn)行了有效分析和利用，但是在幀層，甚至是基本的單元層實(shí)現(xiàn)了優(yōu)化的比特分配，其應(yīng)用范圍也逐漸廣泛，并且使用Lagrangian優(yōu)化技術(shù)之后，其失真性能得到了一定的改善。然而，在實(shí)際的應(yīng)用中卻沒有充分考慮視頻幀關(guān)于場(chǎng)景變換，其他的復(fù)雜度等這類因素，同時(shí)也沒有合理結(jié)合視覺感知特征設(shè)計(jì)碼率控制方法，導(dǎo)致若干視頻傳輸依然是目前研究工作中的重點(diǎn)和難點(diǎn)。

2互聯(lián)網(wǎng)的若干視頻傳輸關(guān)鍵技術(shù)研究

2.1面向信道編碼的糾錯(cuò)技術(shù)分析

視頻編碼器的存在主是為了提高視頻的壓縮效率，通常情況下是基于宏塊的幀間預(yù)測(cè)，運(yùn)動(dòng)補(bǔ)償技術(shù)來(lái)實(shí)現(xiàn)的，進(jìn)而視頻幀間的產(chǎn)解碼依賴關(guān)系便會(huì)增強(qiáng)。在大量移動(dòng)設(shè)備借助Wi-Fi、4G這類移動(dòng)通信網(wǎng)接入了互聯(lián)網(wǎng)，造成Rayleigh衰減以及網(wǎng)絡(luò)擁塞等情況頻發(fā)。為此對(duì)視頻傳輸?shù)目煽啃?、穩(wěn)定性的相關(guān)要求則為更加嚴(yán)格。因此需要在實(shí)際的應(yīng)用過程中對(duì)丟包事件進(jìn)行建模，以加強(qiáng)視頻幀與幀之間的聯(lián)系，同時(shí)也借助數(shù)據(jù)分析加強(qiáng)糾錯(cuò)技術(shù)的應(yīng)用，從而使視頻傳輸更加快速。

2.2自適應(yīng)遺傳算法的糾錯(cuò)方法

這種計(jì)算方法主要是利用SVC平均失真計(jì)算方法，因?yàn)閟vc的時(shí)間具有可伸縮編碼，其采用的主要是層級(jí)B幀編碼技術(shù)，而時(shí)間分層中的低層重要作用是對(duì)高層的正確解碼。若是低層數(shù)據(jù)發(fā)生丟失，隨讓解碼器應(yīng)用了錯(cuò)誤隱藏的技術(shù)，但是最終也會(huì)擴(kuò)散比較嚴(yán)重。也會(huì)將錯(cuò)誤擴(kuò)散至高層。因此在發(fā)生數(shù)據(jù)包丟失的事件時(shí)候，若是處于網(wǎng)絡(luò)傳輸?shù)沫h(huán)境下，通過計(jì)算SVC在傳輸?shù)倪^程中因?yàn)閬G包造成的失真對(duì)實(shí)現(xiàn)若干視頻傳輸具有重要的作用。

2.3對(duì)擁塞控制的視頻組播傳輸技術(shù)進(jìn)行分析

為了進(jìn)一步滿足視頻會(huì)議以及音/視頻廣播等的應(yīng)用，甚至于網(wǎng)絡(luò)游戲的應(yīng)用，視頻組播逐漸成為互聯(lián)網(wǎng)中比較重要的應(yīng)用之一，而與其相關(guān)的組播擁塞控制便是比較重要的分析內(nèi)容。也成為當(dāng)前一個(gè)非常重要的研究?jī)?nèi)容。為此能有效滿足視頻傳輸實(shí)時(shí)性要求的擁塞控制方法成為現(xiàn)階段研究的重點(diǎn)內(nèi)容之一。在當(dāng)代比較典型的組播擁塞控制方法主要有以下幾點(diǎn)：例如PIM以及MOSPF兩種，其主要的內(nèi)容為在計(jì)算發(fā)送端、接收端之間最短路由進(jìn)行最小化組播樹的代價(jià)，而若是多個(gè)組播組時(shí)同時(shí)存在的時(shí)候卻無(wú)法保證了網(wǎng)絡(luò)流量的均衡性?；诖搜芯拷M播擁塞控制方法，對(duì)維護(hù)互聯(lián)網(wǎng)穩(wěn)定運(yùn)行，均衡網(wǎng)絡(luò)負(fù)載以及提高視頻傳輸可靠性的作用重大?，F(xiàn)階段主要應(yīng)用在視頻組播系統(tǒng)的組播擁塞控制方法為RLM、FLID-DL以及PGMCC等，因?yàn)槠渚鶝]有對(duì)互聯(lián)網(wǎng)或者視頻數(shù)據(jù)編解碼的加以分析和優(yōu)化，進(jìn)而沒有辦法完成完整的組播擁塞控制功能。因此人們?cè)诨ヂ?lián)網(wǎng)中邊緣路由器進(jìn)行了設(shè)計(jì)，即優(yōu)先級(jí)分組標(biāo)記算法，另外也在核心路由器中導(dǎo)入了優(yōu)先級(jí)區(qū)分的分組丟棄算法，即所謂的新分層組播擁塞控制方法，然而在實(shí)際的應(yīng)用中此方法則是完全依賴路由器的支持，很難付諸實(shí)際并加以利用。除此之外也還能夠利用可伸縮視頻編碼和跨層優(yōu)化技術(shù)一起結(jié)合，將分層組播傳輸協(xié)議加以分析并且對(duì)擁塞控制的方法進(jìn)行完善，此方法結(jié)合了物理層以及鏈路層、網(wǎng)絡(luò)層的功能，實(shí)際的復(fù)雜度比較高，應(yīng)用受到了極大的限制。因此在實(shí)際的應(yīng)用中應(yīng)該慎重選擇，實(shí)現(xiàn)效果比較顯著的則是多速率組播擁塞控制模型，這一模型歲數(shù)據(jù)的恢復(fù)具有一定的作用。

2.4對(duì)視覺感知的碼率控制方法分析

此種方法主要是以宏塊局部運(yùn)動(dòng)性為依據(jù)，將幀的活動(dòng)度進(jìn)行了定義，從而把視覺感知適當(dāng)應(yīng)用在可察覺失真中，并且基于SSIM的率失真模型，將視頻幀中時(shí)間、空間存在的冗余進(jìn)行消除。之后將BU層、幀層將的比特分配方案進(jìn)行分析、設(shè)計(jì)，讓其更加符合人眼的視覺感知特征，進(jìn)而達(dá)到提高編碼效率的目的。這種方法的提出不但使輸出碼流穩(wěn)定性增加，同時(shí)也顯著提高了碼率控制的精以及視頻的質(zhì)量。

2.5對(duì)SMDP單播擁塞控制方法進(jìn)行分析

這一方法的主要是通過分析每一個(gè)GOP傳輸后失真的期望值，并且將視頻序列平均失真進(jìn)行計(jì)算，并以此為基礎(chǔ)把單播擁塞控制作為馬爾科夫性質(zhì)的離散過程，使用SMDP進(jìn)行擁塞控制建模，同時(shí)計(jì)算相應(yīng)的求解算法，借此優(yōu)化擁塞控制參數(shù)，進(jìn)而有效地提升了接收端視頻的主觀和客觀質(zhì)量。

3結(jié)束語(yǔ)

本文通過將互聯(lián)網(wǎng)的視頻傳輸進(jìn)行研究，將其目前存在的進(jìn)行分析，并且對(duì)糾錯(cuò)方法以及基于擁塞控制的視頻傳輸技術(shù)這類內(nèi)容加以分析，提出了相應(yīng)的解決方法，進(jìn)而達(dá)到若干視頻高質(zhì)量、高速度共同傳輸?shù)哪康摹?/p>

參考文獻(xiàn)

[1]田波.面向互聯(lián)網(wǎng)的若干視頻傳輸關(guān)鍵技術(shù)研究[D].廣東工業(yè)大學(xué)，2014.

[2]毛年勝，卓力.基于H.264SVC的IP網(wǎng)絡(luò)視頻傳輸系統(tǒng)的實(shí)現(xiàn)[J].測(cè)控技術(shù)，2010，29（5）：5~8.

[3]程振宇，張燦，和智濤，等.基于3G網(wǎng)絡(luò)視頻傳輸?shù)囊环NQoS控制方法[J].中國(guó)科學(xué)院大學(xué)學(xué)報(bào)，2014，31（1）：117~123.

[4]王峰，蔡敬菊，魏宇星，等.基于無(wú)線網(wǎng)絡(luò)的實(shí)時(shí)視頻傳輸系統(tǒng)的設(shè)計(jì)[J].微電子學(xué)與計(jì)算機(jī)，2012，29（5）：58~61.

篇3

關(guān)鍵詞：實(shí)時(shí)傳輸協(xié)議；實(shí)時(shí)傳輸控制協(xié)議；視頻傳輸

中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1009-3044(2007)04-10969-02

1 引言

隨著計(jì)算機(jī)技術(shù)、網(wǎng)絡(luò)技術(shù)、視頻壓縮編碼技術(shù)等關(guān)鍵技術(shù)的飛速發(fā)展，網(wǎng)絡(luò)視頻傳輸技術(shù)以其實(shí)時(shí)性和直觀性等到了越來(lái)越多的重視。但是網(wǎng)絡(luò)狀況經(jīng)常變化，在網(wǎng)絡(luò)上實(shí)時(shí)傳輸音頻/視頻流，必須采取防止擁塞的措施，才能保證其服務(wù)質(zhì)量QoS。

通常采用實(shí)時(shí)傳輸協(xié)議RTP來(lái)調(diào)整碼流量來(lái)匹配網(wǎng)絡(luò)帶寬的變化，利用RTP協(xié)議的反饋信息來(lái)估計(jì)網(wǎng)絡(luò)狀態(tài)，然后根據(jù)評(píng)估的網(wǎng)絡(luò)狀態(tài)，調(diào)整發(fā)送端的傳輸率，以此來(lái)支持網(wǎng)絡(luò)實(shí)時(shí)傳輸服務(wù)，提供多媒體數(shù)據(jù)傳輸?shù)膶?shí)時(shí)標(biāo)準(zhǔn)，實(shí)現(xiàn)自適應(yīng)網(wǎng)絡(luò)傳輸。

2 實(shí)時(shí)傳輸協(xié)議RTP

RTP協(xié)議實(shí)際上由實(shí)時(shí)傳輸協(xié)議RTP（Real-time Transport Protocol）和實(shí)時(shí)傳輸控制協(xié)議RTCP（Real-time Transport Control Protocol）兩部分組成。RTP協(xié)議基于多播或單播網(wǎng)絡(luò)為用戶提供連續(xù)媒體數(shù)據(jù)的實(shí)時(shí)傳輸服務(wù)；RTCP協(xié)議是RTP協(xié)議的控制部分，用于實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)傳輸質(zhì)量，為系統(tǒng)提供擁塞控制和流控制。

由于RTP可以運(yùn)載在任何協(xié)議之上，所以RTP協(xié)議的應(yīng)用可以不僅僅局限在多媒體傳輸領(lǐng)域，還可以應(yīng)用于其它領(lǐng)域。雖然在特殊領(lǐng)域應(yīng)用RTP'協(xié)議只需在原來(lái)的基礎(chǔ)上根據(jù)領(lǐng)域的特定應(yīng)用做進(jìn)一步限定，但到目前為止，除了一些研究項(xiàng)目以外，RTP協(xié)議主要還是應(yīng)用于音頻/視頻傳輸方面。

3 視頻數(shù)據(jù)的傳輸過程

3.1 媒體數(shù)據(jù)的分包策略

視頻數(shù)據(jù)在進(jìn)行網(wǎng)絡(luò)傳輸之前，應(yīng)首先進(jìn)行數(shù)據(jù)包大小的分割。這是因?yàn)镽TP協(xié)議通常是基于UDP協(xié)議的，而UDP協(xié)議對(duì)數(shù)據(jù)包的大小有規(guī)定，超過部分可能會(huì)丟掉，對(duì)于視頻數(shù)據(jù)來(lái)說(shuō)，某些壓縮的關(guān)鍵幀很大，很可能超過UDP協(xié)議所規(guī)定的最大值；另外，媒體數(shù)據(jù)的關(guān)鍵幀與非關(guān)鍵幀數(shù)據(jù)量相差很遠(yuǎn)，而路由器一般都采用支持小包優(yōu)先的原則，有可能使數(shù)據(jù)量較小的非關(guān)鍵幀比它前面的數(shù)據(jù)量大的關(guān)鍵幀更早地到達(dá)接收方，而導(dǎo)致亂序。因此媒體數(shù)據(jù)在進(jìn)行傳輸前，要首先進(jìn)行分包。

對(duì)于媒體數(shù)據(jù)的分包一般基于兩個(gè)條件：（1）數(shù)據(jù)包大小的確定。主要根據(jù)提供網(wǎng)絡(luò)帶寬、多媒體類型和所采用的傳輸協(xié)議來(lái)確定；（2）盡量包含完整的數(shù)據(jù)塊信息。主要和壓縮編碼方式有關(guān)。

3.2 數(shù)據(jù)包的發(fā)送過程

媒體數(shù)據(jù)的發(fā)送過程是將壓縮編碼器產(chǎn)生的數(shù)據(jù)流(壓縮編碼器按照固定的頻率產(chǎn)生數(shù)據(jù)包)送到媒體緩沖區(qū)，經(jīng)過容錯(cuò)處理后，交給RTP層對(duì)媒體數(shù)據(jù)重新組包，加上RTP包頭，再送給下層進(jìn)行傳輸（如圖1所示）。

圖1 媒體流的發(fā)送過程

媒體數(shù)據(jù)的發(fā)送過程分以下幾步：

（1）判斷是否有用戶需求；

（2）若有，則將壓縮編碼產(chǎn)生的數(shù)據(jù)包放入網(wǎng)絡(luò)傳輸緩沖區(qū)，進(jìn)行容錯(cuò)處理后，交給RTP層；

（3）RTP層對(duì)媒體數(shù)據(jù)重新組織，加上RTP報(bào)文頭，生成RTP報(bào)文交給下層；

（4）按照系統(tǒng)按定的IP地址發(fā)送給相應(yīng)的用戶。

3.3 數(shù)據(jù)包的接收過程

由于系統(tǒng)采用的傳輸協(xié)議是UDP協(xié)議，數(shù)據(jù)包在傳輸過程中，可能出現(xiàn)亂序，因此必須在接收方采用一定的措施進(jìn)行數(shù)據(jù)接收。一個(gè)可行的方法是在接收方建立一個(gè)環(huán)行緩沖區(qū)隊(duì)列，用于存儲(chǔ)接收到的數(shù)據(jù)信息。其工作過程如圖2所示，（a）為初始狀態(tài)，（b）為接收到第一個(gè)數(shù)據(jù)包，（c）為接收到兩個(gè)數(shù)據(jù)包，（d）為讀走一個(gè)數(shù)據(jù)包。

圖2 緩沖區(qū)工作過程

緩沖區(qū)隊(duì)列設(shè)置兩個(gè)指針pEmpty和pData，pEmpty指示環(huán)行緩沖區(qū)隊(duì)列中第一個(gè)空緩沖區(qū)的位置，pData指示環(huán)行緩沖區(qū)隊(duì)列第一個(gè)數(shù)據(jù)的位置。在通信前，各隊(duì)列中的緩區(qū)的標(biāo)志都為“空”，pEmpty指向環(huán)行緩沖區(qū)隊(duì)列的隊(duì)首，pData為空。通信開始后，系統(tǒng)將接收到的數(shù)據(jù)包存入pEmpty指針?biāo)甘镜木彌_區(qū)中，將該緩沖區(qū)標(biāo)志設(shè)置為“非空”，同時(shí)，將pEmpty指針移到下一個(gè)空緩沖區(qū)位置，媒體播放模塊每取出一個(gè)數(shù)據(jù)包，就把pData指針指示的緩沖區(qū)標(biāo)志重新設(shè)“空”，并將pData指針移到下一個(gè)數(shù)據(jù)緩沖區(qū)位置。

（1）接收算法

設(shè)置緩沖優(yōu)先隊(duì)列Q存放已接收到但還未處理的幀，優(yōu)先數(shù)為幀所帶的序號(hào)，設(shè)Q的元素集合為R，|R|=nQ，Q的容限為NQ（nQ

圖3 緩沖區(qū)工作過程

其中：（1）為了保證實(shí)時(shí)性；（2）為了保證傳輸?shù)牟恢貜?fù)性；（3）中選擇丟棄優(yōu)先數(shù)最小的幀，能使隊(duì)列中每一元素的處理時(shí)間都提前，這是為了保證實(shí)時(shí)性。

（2）取視頻數(shù)據(jù)的算法

從緩沖區(qū)取數(shù)據(jù)采取步驟：

①找出緩沖區(qū)優(yōu)先數(shù)最小的幀；

②將接收RTP報(bào)文的情況告知QoS監(jiān)控器；

③在RTP層經(jīng)過解包，去掉RTP報(bào)文頭；

④送給上層播放；

⑤在緩沖區(qū)Q中刪除該幀。

4 結(jié)束語(yǔ)

本文研究了RTP/UDP在流媒體領(lǐng)域得到了廣泛的應(yīng)用，探討了其在視頻實(shí)時(shí)傳輸過程中對(duì)視頻數(shù)據(jù)分包策略以及傳輸過程的應(yīng)用。網(wǎng)絡(luò)視頻傳輸?shù)膶?shí)現(xiàn)無(wú)疑會(huì)極大地開拓多媒體通信的應(yīng)用領(lǐng)域，使網(wǎng)絡(luò)信息更直觀、更生動(dòng)。在信息產(chǎn)業(yè)飛速發(fā)展的今天，視頻等多媒體網(wǎng)絡(luò)實(shí)時(shí)傳輸技術(shù)具有廣闊的應(yīng)用前景。

參考文獻(xiàn)：

[1]Anthony Jones, Jim Ohlund.網(wǎng)絡(luò)編程技術(shù)[M].北京：機(jī)械工業(yè)出版社，2000.

[2]Sandawi Tarek N.等著.遠(yuǎn)程通信網(wǎng)絡(luò)基礎(chǔ)[M]，黃巖等譯.北京：電子工業(yè)出版社，1996.

[3][美]斯坦伯姆著，曾華深等譯. 計(jì)算機(jī)網(wǎng)絡(luò)（第二版）[M].成都：成都科技大學(xué)出版社，1989.

篇4

相關(guān)技術(shù)簡(jiǎn)介

1　雙絞線技術(shù)

雙絞線是一種柔性的通信電纜，包含著成對(duì)的絕緣銅線，因?yàn)樗哂锌垢蓴_能力強(qiáng)、傳輸距離遠(yuǎn)、布線容易、價(jià)格低廉等許多優(yōu)點(diǎn)，價(jià)格便宜，所以被廣泛使用。由于雙絞線對(duì)信號(hào)也存在著較大的衰減，所以傳輸距離遠(yuǎn)時(shí)，信號(hào)的頻率不能太高，而高速信號(hào)如以太網(wǎng)則只能限制在100m以內(nèi)。對(duì)于視頻信號(hào)而言，帶寬達(dá)到6MHz，如果直接在雙絞線內(nèi)傳輸，也會(huì)衰減很大，所以視頻信號(hào)在雙絞線上要實(shí)現(xiàn)遠(yuǎn)距離傳輸，必須進(jìn)行放大和補(bǔ)償，雙絞線視頻傳輸設(shè)備就是完成這種功能。加上一對(duì)雙絞線視頻收發(fā)設(shè)備后，可以將圖像傳輸?shù)?～2km。雙絞線和雙絞線視頻傳輸設(shè)備價(jià)格都很便宜，不但沒有增加系統(tǒng)造價(jià)，反而在距離增加時(shí)其造價(jià)與同軸電纜相比下降了許多。所以，監(jiān)控系統(tǒng)中用雙絞線進(jìn)行傳輸具有明顯的優(yōu)勢(shì)。

2　互導(dǎo)型放大器

互導(dǎo)型放大器(又稱跨導(dǎo)型放大器)的輸入信號(hào)是電壓量，輸出信號(hào)是電流量，其增益稱為互導(dǎo)Gm。互導(dǎo)型放大器是一種電壓／電流模式混合電路，由于其內(nèi)部只有電壓――電流變換級(jí)和電流傳輸級(jí)，而沒有電壓傳輸級(jí)，因此沒有大擺幅電壓信號(hào)和密勒倍增效應(yīng)，從而具有頻帶寬、高頻性能好及大信號(hào)轉(zhuǎn)換速度高等特性。互導(dǎo)型放大器的電路結(jié)構(gòu)簡(jiǎn)單，電源電壓和功耗均得到了降低。

驅(qū)動(dòng)電路采用互導(dǎo)型放大器將單端電壓信號(hào)轉(zhuǎn)成差分電流信號(hào)，通過電流環(huán)在雙絞線上傳輸視頻信號(hào)，接收端再把差分電流信號(hào)還原為單端電壓信號(hào)。

3　MAX435和MAX436

在這里互導(dǎo)型放大器采用MAXIM公司的MAX435和MAX436作為雙絞線視頻信號(hào)電路驅(qū)動(dòng)。MAX435和MAX436是一種新型高速、寬帶的互導(dǎo)型放大器，其引腳排列如圖1、圖2所示。它們具有理想差分、高阻抗輸入和電流輸出等特點(diǎn)。由于這些獨(dú)特的結(jié)構(gòu)，該芯片能夠提供精確增益，不用負(fù)反饋就能消除閉環(huán)相移。

設(shè)計(jì)與實(shí)現(xiàn)方法

1　電路設(shè)計(jì)

當(dāng)傳輸距離小于1500m時(shí)，采用雙絞線來(lái)傳遞基帶視頻信號(hào)也能獲得很好的效果。和使用傳統(tǒng)的同軸電纜相比，用雙絞線傳輸信號(hào)時(shí)要注意兩點(diǎn)：采用平衡(差分)傳輸以使共模噪聲最小；恰當(dāng)端接以使反射最小。由于MAX435和MAX436在10MHz時(shí)共模抑制比能達(dá)到53dB。而且輸入輸出阻抗又都很高，所以特別適用于這樣的應(yīng)用場(chǎng)合。

實(shí)際電路如圖2所示。從圖中看出，MAX435和MAX436組成雙絞線視頻傳輸電路的驅(qū)動(dòng)器／接收器，只采用一個(gè)差分輸出的MAX435即可驅(qū)動(dòng)平衡雙絞線(其輸入信號(hào)以地為基準(zhǔn))，從而省去了平衡變壓器或兩個(gè)單端輸出驅(qū)動(dòng)器。為了實(shí)現(xiàn)平衡到單端線路的變換，其接收器電路采用了單端輸出的MAX436。IN+到IN-間的100Ω電阻器使線路的終端連接十分合理?；?dǎo)網(wǎng)絡(luò)(從z+到z-)不僅完成增益調(diào)節(jié)(+6dB)。而且還起到線路均衡的作用，從而提高接收器的高頻增益。

在圖3電路中，可以通過調(diào)整R1提高整體增益對(duì)歐姆損耗進(jìn)行補(bǔ)償來(lái)得到合適的亮度，通過調(diào)整C1(增添零／極點(diǎn)對(duì)以擴(kuò)展頻帶)來(lái)獲得最佳的色彩。由于調(diào)整是在接收器端進(jìn)行的，所以用戶可以在接收端一邊觀察屏幕一邊調(diào)整R1和C1，從而得到最佳圖像。

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

圖3(a)和圖3(b)是從監(jiān)視器屏幕上看到的調(diào)節(jié)前、后的視頻脈沖波形。試驗(yàn)結(jié)果表明，當(dāng)本電路用165m長(zhǎng)的φ0.71mm防盜報(bào)警器用雙絞線傳送NTSC基帶視頻信號(hào)時(shí)，3.58MHz色同步信號(hào)的衰減約為6dB。雖有失真，但由于監(jiān)視器對(duì)信號(hào)衰減具有自動(dòng)均衡補(bǔ)償(對(duì)色同步信號(hào)的衰減補(bǔ)償可達(dá)10dB)，故圖像質(zhì)量仍然很好，無(wú)明顯彩色變淡或水平分辨率變差的現(xiàn)象。但若衰減量進(jìn)一步增大，則色度和水平分辨率變差、難以看清顯示的圖文。

當(dāng)本電路用長(zhǎng)330m的電話雙絞線在兩幢大樓之間傳送NTSC錄像機(jī)視頻信號(hào)時(shí)。圖像質(zhì)量良好。又故意在兩根平衡的絞線上各加上圖3(c)所示的50Hz的共模噪聲電壓進(jìn)行試驗(yàn)，圖像質(zhì)量未受影響。

這是由于MAX436對(duì)60Hz信號(hào)具有60dB的共模抑制比，使這種噪聲不致影響圖像。如果用不平衡的單端方式來(lái)驅(qū)動(dòng)電纜，則效果之差是可以預(yù)料的。雖然上述試驗(yàn)只用了NTSC視頻信號(hào)，但本電路用于載波為4.43MHz的PAL制視頻信號(hào)仍可取得相似的效果。

結(jié)論

在許多不要求電纜具有很寬的帶寬的場(chǎng)合中，用雙絞線代替昂貴的同軸電纜不僅可以降低線路的鋪設(shè)成本，而且兩根絞線感應(yīng)的差分干擾電流可以互相抵消。只要采用適當(dāng)?shù)慕g線，并在接收端的監(jiān)視器進(jìn)行阻抗匹配和自動(dòng)增益補(bǔ)償(目前大多數(shù)電視監(jiān)視器都具有此功能)，其傳送基帶(復(fù)合)視頻信號(hào)的距離可遠(yuǎn)達(dá)1500kin，而且圖像質(zhì)量并不差，能夠保證圖像色彩、亮度、輪廓等基本無(wú)失真。

篇5

【關(guān)鍵詞】802.11；視頻傳輸；服務(wù)質(zhì)量；包調(diào)度

1.引言

802.11協(xié)議組是國(guó)際電工電子工程學(xué)會(huì)（IEEE）為無(wú)線局域網(wǎng)（WLAN）絡(luò)制定的標(biāo)準(zhǔn)[1]，已經(jīng)被廣泛應(yīng)用于企業(yè)、學(xué)校、酒店、商場(chǎng)等各種領(lǐng)域。實(shí)時(shí)視頻業(yè)務(wù)是802.11網(wǎng)絡(luò)所承載的重要業(yè)務(wù)數(shù)據(jù)類型。實(shí)時(shí)視頻傳輸過程中隨機(jī)的丟包會(huì)導(dǎo)致視頻質(zhì)量不可控的惡化，為了增加WLAN對(duì)QoS（quality of service，服務(wù)質(zhì)量）的支持，802.11工作組在DCF（Distributed Coordination Function）協(xié)議的基礎(chǔ)上引入了EDCA（Enhanced Distributed Channel Access）協(xié)議和HCCA（Hybrid Coordination Function Controlled Channel Access）協(xié)議。但是EDCA協(xié)議和HCCA協(xié)議并沒有考慮視頻包的內(nèi)容，本文研究了以提高視頻傳輸質(zhì)量為最終目的MAC層隊(duì)列調(diào)度算法。當(dāng)網(wǎng)絡(luò)資源受限時(shí)，該算法優(yōu)先把網(wǎng)絡(luò)資源分配給重要的視頻包，最大程度的減少了視頻傳輸?shù)馁|(zhì)量的惡化。

2.相關(guān)研究

EDCA協(xié)議在MAC層定義了四個(gè)優(yōu)先級(jí)隊(duì)列，分別是AC_VO、AC_VI、AC_BE和AC_BK，對(duì)應(yīng)于語(yǔ)音業(yè)務(wù)流、視頻業(yè)務(wù)流、數(shù)據(jù)業(yè)務(wù)流和背景流。Ksentini等[2]針對(duì)WLAN中帶數(shù)據(jù)分割的H.264視頻流的傳輸，提出一種跨層的傳輸框架（CL-ARCH，Cross-Layer Architecture）。CL-ARCH根據(jù)視頻包的重要性，把不同類型的視頻包分別映射到AC_VO，AC_VI和AC_BE。Chilamkurti等[3]提出了一種跨層的動(dòng)態(tài)映射算法來(lái)提高H.264視頻在WLAN網(wǎng)絡(luò)中的傳輸。在這種動(dòng)態(tài)算法中，MAC層調(diào)度器根據(jù)MAC層隊(duì)列的長(zhǎng)度和視頻包的重要性，把視頻包映射到三個(gè)不同的隊(duì)列。在文獻(xiàn)[4]中，作者提出了一種細(xì)粒度的優(yōu)化映射算法，即根據(jù)視頻包的優(yōu)先級(jí)和當(dāng)前的網(wǎng)絡(luò)狀態(tài)建立一個(gè)線性優(yōu)化模型，并求解出最優(yōu)的映射方案，進(jìn)一步提出視頻傳輸?shù)馁|(zhì)量。Du和Chen[5]提出了一種延時(shí)感知的傳輸框架（DATF，Deadline-aware Transmission Framework），DATF不盡進(jìn)行了類型映射，還估計(jì)了每個(gè)視頻包的傳輸延時(shí)并將可能超時(shí)的包主動(dòng)丟棄。本文的主要?jiǎng)?chuàng)新是提出了一個(gè)低復(fù)雜度的包調(diào)度算法?；贛/M/1隊(duì)列模型，該算法給每一個(gè)視頻包引入一個(gè)附加延時(shí)，這個(gè)延時(shí)的值可以是正值或負(fù)值。正值表示增加了該包的延時(shí)，負(fù)值表示減少了它的延時(shí)?；谝曨l包的失真估計(jì)和當(dāng)前的隊(duì)列長(zhǎng)度，調(diào)度器建立了一個(gè)以最小化失真為目標(biāo)的優(yōu)化函數(shù)，并通過求解函數(shù)獲得每一個(gè)視頻包的附加延時(shí)。

3.視頻包的失真估計(jì)

如何簡(jiǎn)單而有效的度量視頻包的重要性仍然是一個(gè)尚未解決的問題。傳輸失真估計(jì)往往需要在復(fù)雜度和精確度之間尋求平衡。本文使用了一種簡(jiǎn)單的方法估計(jì)傳輸失真。假設(shè)視頻序列分割成很多個(gè)GOP（Group of Picture）單元，每個(gè)GOP包括一個(gè)I幀和若干個(gè)P幀或B幀。所有的視頻幀可以分成參考幀（reference frame）和非參考幀（non-reference frame）。

首先，設(shè)非參考幀的傳輸失真定義為單位“1”，即D{F}=1。D{F}表示視頻幀F(xiàn)的傳輸失真。參考幀的傳輸失真用遞歸公式D{Fj}=D{Fi（j，L）}+1計(jì)算，其中視頻幀F(xiàn)i（j，L）使用Fj作為它的參考幀。設(shè)Dmax是這個(gè)GOP中傳輸失真的最大值，則歸一化的傳輸失真（記為d）定義為：

4.包調(diào)度算法

在用戶節(jié)點(diǎn)開始啟動(dòng)退避計(jì)數(shù)器之前，調(diào)度器需要根據(jù)一定的調(diào)度規(guī)則從MAC層隊(duì)列中挑選一個(gè)待發(fā)送的視頻包。本文基于排隊(duì)理論的分析，提出一種針對(duì)視頻實(shí)時(shí)應(yīng)用調(diào)度算法，該算法綜合考慮了視頻包的傳輸失真和當(dāng)前的隊(duì)列信息。

假設(shè)用戶節(jié)點(diǎn)的MAC隊(duì)列符合一個(gè)簡(jiǎn)單的M/M/1隊(duì)列模型，且隊(duì)列長(zhǎng)度為L(zhǎng)。設(shè)pi是當(dāng)前隊(duì)列中第i個(gè)視頻包，是pi超時(shí)丟失的概率，i=1，2，L，L。為了保護(hù)重要的視頻包，我們給每一個(gè)視頻包引入了一個(gè)附加的額外延時(shí)，記為。特別強(qiáng)調(diào)的是，可以是一個(gè)正值，也可以是一個(gè)負(fù)值，且有。正值表示視頻包延時(shí)的增加，而負(fù)值對(duì)應(yīng)著視頻包延時(shí)的減少。按照排隊(duì)理論，有，式中表示deadline，和是兩個(gè)常數(shù)。

此時(shí)，隊(duì)列中所有視頻包總的傳輸失真可以表示為：

（1）

式（1）中，di表示pi的傳輸失真。為了最小化dtotal，我們需要處理一個(gè)限制條件為的優(yōu)化問題。使用Lagrangian法求解可得：

（2）

根據(jù)排隊(duì)理論，有：

（3）

設(shè)表示隊(duì)列長(zhǎng)度的平均值，且E{L|L>1} ≈。把公式（3）代入（2）有：

（4）

篇6

關(guān)鍵詞：FMS 跨平臺(tái) RTMP ffmpeg HLS

中圖分類號(hào)：TN919.8 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1007-9416（2016）11-0106-02

1 系統(tǒng)整體方案

FMS（Flash Media Service）是Adobe公司出品的流媒體服務(wù)器，同時(shí)也是極具彈性的開發(fā)環(huán)境，它提供了強(qiáng)大的多用戶、高質(zhì)量音視頻功能，自適應(yīng)不同的帶寬環(huán)境，可用于創(chuàng)建多樣的交互多媒體網(wǎng)絡(luò)應(yīng)用。FMS除了大量應(yīng)用于各類視頻網(wǎng)站，對(duì)視頻會(huì)議、視頻監(jiān)控、多媒體教學(xué)等領(lǐng)域，也都能提供方便優(yōu)質(zhì)的流媒體服務(wù)。目前國(guó)內(nèi)一些廠商的多媒體服務(wù)平臺(tái)也是基于FMS開發(fā)的。

然而，隨著Android和IOS系統(tǒng)停止對(duì)flash的原生支持，實(shí)現(xiàn)一個(gè)跨平臺(tái)的統(tǒng)一視頻服務(wù)變得困難，往往需要從底層開始自主研發(fā)，成本高且通用性差。從FMS4.5版本之后開始支持的Http Dynamic Streaming技術(shù)針對(duì)蘋果的HLS方案提出了基于HTTP的流媒體傳輸方案，增加了對(duì)HLS協(xié)議的支持，解決了移動(dòng)端播放視頻格式的問題，這為FMS服務(wù)于不同的終端提供了便捷的技術(shù)支持。

具體的PC客戶端仍可采用Flex技術(shù)，方便地實(shí)現(xiàn)視頻流的上傳和播放，其中視頻的上傳利用rtmp協(xié)議，播放采用flash技術(shù)；針對(duì)移動(dòng)端視頻傳輸，向服務(wù)器推流也必須符合rtmp協(xié)議。在android和IOS系統(tǒng)要實(shí)現(xiàn)rtmp推流有多種技術(shù)方案可選，綜合考慮開發(fā)成本和視頻格式的統(tǒng)一性，本文主要介紹利用ffmpeg原生代碼，并移植到android和IOS系統(tǒng)的解決方案。移動(dòng)端的播放則借助HLS協(xié)議，最終實(shí)現(xiàn)跨平臺(tái)的視頻傳輸。

2 PC端采用flex技術(shù)實(shí)現(xiàn)視頻傳輸

flex同為Adobe公司的產(chǎn)品，結(jié)合FMS進(jìn)行開發(fā)尤為簡(jiǎn)便，但需要flash技術(shù)支持。這在臺(tái)式電腦操作系統(tǒng)中不成問題，但運(yùn)用在移動(dòng)端需借助Adobe AIR技術(shù)較困難，考慮到兼容性等諸多因素，使用并不廣泛，所以當(dāng)前在移動(dòng)端不建議采用。

PC端運(yùn)用Flex結(jié)合FMS實(shí)現(xiàn)視頻點(diǎn)播、直播的關(guān)鍵代碼如下：

2.1 點(diǎn)播服務(wù)器上的視頻文件

nc.connect（"rtmp：// FMS服務(wù)器IP地址：端口號(hào)/PlayStreams路徑"）；//連接FMS

ns=new NetStream（nc）；

ns.play（"視頻文件名"，0）；

2.2 向服務(wù)器推流，用于直播

nc.connect（"rtmp：//FMS服務(wù)器IP地址：端口號(hào)/LiveStreams路徑"）；//連接FMS

ns=new NetStream（nc）；

ns.attachCamera（cam）；//調(diào)用攝像頭

ns.attachAudio（mic）；//調(diào)用麥克風(fēng)

ns.publish（“視頻流名稱”，"live"）；

2.3 播放直播流

nc.connect（"rtmp：//FMS服務(wù)器IP地址：端口號(hào)/LiveStreams路徑"）；//連接FMS

ns=new NetStream（nc）；

ns.play（"視頻流名稱"）；//對(duì)應(yīng)于視頻流端的publish（"視頻流名稱"，"live"）.

其中nc為NetConnection類型對(duì)象，用于連接FMS；ns為NetStream類型對(duì)象，代表視頻流。

3 移動(dòng)端實(shí)現(xiàn)視頻

利用FMS作為視頻服務(wù)器，要求視頻推流符合RTMP協(xié)議。在移動(dòng)端有多種開發(fā)庫(kù)可以實(shí)現(xiàn)，例如商業(yè)上應(yīng)用比較多的vitamio、ijkplayer、ffplayer等，本質(zhì)上它們都是基于ffmpeg的開源項(xiàng)目。直接使用這些開發(fā)庫(kù)，開發(fā)周期短難度低，但技術(shù)上總受到諸多限制。所以本文介紹直接使用FFMPEG實(shí)現(xiàn)視頻處理，而后移植到移動(dòng)端操作系統(tǒng)中的開發(fā)方法，更加靈活可控。

3.1 ffmpeg推流

ffmpeg實(shí)現(xiàn)視頻推流首先需指定協(xié)議，然后向服務(wù)器寫入視頻數(shù)據(jù)。核心函數(shù)如下：

avformat_alloc_output_context2（&outfmt_ctx， NULL， "flv"， out_filename）； //初始化outfmt_ctx

avformat_write_header（outfmt_ctx， NULL）； //寫文件頭

av_interleaved_write_frame（outfmt_ctx， &pkt）； //寫幀，需循環(huán)執(zhí)行

av_write_trailer（outfmt_ctx）； //寫文件尾

其中outfmt_ctx為AVFormatContext類型指針，pkt為AVPacket類型結(jié)構(gòu)體， out_filename為FMS服務(wù)器地址，型如 rtmp：//0.0.0.0/…/livestream。

若要從設(shè)備的攝像頭和麥克風(fēng)采集音視頻數(shù)據(jù)，則程序需要包含libavdevice/avdevice.h文件，并利用其提供的函數(shù)實(shí)現(xiàn)功能。

3.2 ffmepg在android上的移植

ffmpeg用C語(yǔ)言編寫，在android平臺(tái)中使用，需先編譯成.so文件，然后通過JNI（Java Native Interface）調(diào)用，JNI技術(shù)允許Java代碼和其他語(yǔ)言寫的代碼（C&C++）進(jìn)行交互。

編譯ffmpeg可采用android NDK（Native Development Kit）編譯，或在Linux操作系統(tǒng)中（ubuntu）直接做交叉編譯。編譯成功將得到libffmpeg.so、libavfilter.so、libavcodec.so、 libavfomat.so、libavdevice.so、libavuntil.so、libpostproc.so等文件。

將上述.so文件和頭文件導(dǎo)入自己的工程中，并編寫自己的C文件調(diào)用相關(guān)功能，然后配置安卓makefile文件Android.mk。在java程序中使用native？functionname（…）；格式調(diào)用C文件中自己編寫的函數(shù)。

3.3 ffmepg在蘋果系統(tǒng)上的移植

3.3.1 在mac os下使用ffmpeg

在mac os下使用ffmpeg比較簡(jiǎn)單，可以直接安裝。若系統(tǒng)已經(jīng)安裝好brew，只需在終端輸入命令：brew install ffmpeg，等待安裝結(jié)束即可。安裝成功后，可使用命令行來(lái)操作，或在程序中調(diào)用。

3.3.2 編譯在iOS下使用的ffmpeg library庫(kù) .m文件中調(diào)用

編譯在iOS下使用的ffmpeg需使用build-ffmpeg.sh腳本文件，網(wǎng)上也有很多一鍵編譯的腳本提供下載使用。但如果需要根據(jù)自己的需求對(duì)ffmpeg做相應(yīng)剪裁和指定編譯環(huán)境，則需要自己定制configure文件。

編譯成功后，將生成我們需要的libavfilter.a、libavcodec.a、libavfomat.a、libavdevice.a、libavuntil.a 等.a靜態(tài)庫(kù)。如果沒有指定編譯環(huán)境，一般都支持armv7、armv7s、i386、x86_64、arm64等多個(gè)架構(gòu)。

將編譯好的靜態(tài)庫(kù)拖到xcode工程中，并在自己的.m文件中添加頭文件引用：#include "avformat.h"，就可以使用library庫(kù)了。

4 移動(dòng)端視頻播放

在FMS4.5之前未支持HLS，實(shí)現(xiàn)移動(dòng)端的視頻播放需要rtmp協(xié)議支持，仍可采用移植ffmpeg的方法，也可利用上文提到的Vitamio等開發(fā)庫(kù)。而當(dāng)FMS高版本支持先進(jìn)的HLS協(xié)議之后我們有了更好的選擇，由于HLS數(shù)據(jù)通過HTTP協(xié)議傳輸，所以不用考慮防火墻或者的問題，而且分段文件的時(shí)長(zhǎng)很短，客戶端可以很快的選擇和切換碼率以適應(yīng)不同帶寬條件下的播放。

事實(shí)上，上文提到的視頻開發(fā)庫(kù)都同時(shí)支持rtmp協(xié)議和HLS技術(shù)。另一方面，因?yàn)楝F(xiàn)在版本的android和IOS及其瀏覽器都已經(jīng)支持HTML5標(biāo)準(zhǔn)，在HTML5中播放HLS視頻也可以非常簡(jiǎn)單的使用其video標(biāo)簽，所以對(duì)于客戶端使用瀏覽器的場(chǎng)合，HLS視頻格式顯然是首選方案。而對(duì)于使用APP的客戶端，不管是android還是IOS，如果想利用HTML5編寫應(yīng)用，除了使用開發(fā)庫(kù)，還可以采用高效的混合開發(fā)方式。使用方法如下：

從播放效果看，蘋果的safari運(yùn)行良好，android系統(tǒng)還不是完全穩(wěn)定，適配率不高，這和操作系統(tǒng)版本及使用的瀏覽器有關(guān)。

5 結(jié)語(yǔ)

經(jīng)過十幾年的快速發(fā)展，流媒體技術(shù)方案己經(jīng)非常多樣且不斷發(fā)展。本文針對(duì)視頻傳輸?shù)目缙脚_(tái)需求，主要介紹了基于FMS服務(wù)器和ffmpeg移植的技術(shù)方案，實(shí)現(xiàn)了一個(gè)從技術(shù)難度到開發(fā)成本都相對(duì)合適的視頻傳輸、播放系統(tǒng)，且能在不同帶寬條件下實(shí)現(xiàn)視頻傳輸質(zhì)量最優(yōu)。本系統(tǒng)可在PC、android和ios之間實(shí)現(xiàn)視頻交互，運(yùn)行效果良好，為各類應(yīng)用需求提供了優(yōu)質(zhì)的解決方案。

參考文獻(xiàn)

[1]何圓圓，何凱.基于FFmpeg的H.264視頻解碼器的研究與實(shí)現(xiàn)[J].電腦知識(shí)與技術(shù)，2012.

[2]劉仕坤.手機(jī)平臺(tái)JavaScript語(yǔ)言解釋器設(shè)計(jì)與實(shí)現(xiàn)[D].中南大學(xué)，2009.

[3]周永健.基于FLEX+FMS遠(yuǎn)程交互視頻教學(xué)系統(tǒng)與實(shí)現(xiàn)[D].四川師范大學(xué)，2010.

篇7

關(guān)鍵詞　數(shù)字圖像處理，閉路電視圖像傳輸，ATM 寬帶異步傳輸模式

1 　引言

上海軌道交通3 號(hào)線(明珠線) 閉路電視監(jiān)控系統(tǒng)能提供行車調(diào)度人員對(duì)站臺(tái)人流、列車開關(guān)門情況和站廳出入口等重要區(qū)域的圖像進(jìn)行實(shí)時(shí)觀察、監(jiān)視和控制，以便對(duì)敏感事件進(jìn)行快速反應(yīng)，確保軌道交通運(yùn)營(yíng)中設(shè)備和乘客人身安全及消防應(yīng)急安全。各站圖像除由本站行車值班員監(jiān)視外，還傳送至控制中心，供CCR(中央控制中心) 調(diào)度人員(總調(diào)、列調(diào)和環(huán)調(diào)) 監(jiān)視，從而實(shí)現(xiàn)圖像的遠(yuǎn)程監(jiān)控。

傳統(tǒng)的遠(yuǎn)距離監(jiān)控系統(tǒng)，圖像一般采用光纜或電纜傳輸，易受距離和線路的影響，且造價(jià)極高。近年來(lái)，隨著數(shù)字視頻壓縮技術(shù)和基于ATM 的寬帶綜合業(yè)務(wù)數(shù)據(jù)網(wǎng)的迅速發(fā)展，圖像傳輸也由模擬方式發(fā)展為數(shù)字傳輸，并廣泛應(yīng)用。上海軌道交通3 號(hào)線閉路電視監(jiān)控圖像傳輸系統(tǒng)采用數(shù)字圖像遠(yuǎn)程傳輸，即ATM + H. 261 的方式。

2 　3 號(hào)線數(shù)字圖像遠(yuǎn)程傳輸?shù)奶攸c(diǎn)

2. 1 　不同的圖像傳輸方式的特點(diǎn)

軌道交通閉路電視監(jiān)控系統(tǒng)中車站數(shù)量多、圖像傳輸距離長(zhǎng)，且必須將車站圖像信號(hào)不失真地傳輸至控制中心。在模擬傳輸過程中，視頻信號(hào)對(duì)傳輸距離和轉(zhuǎn)換環(huán)節(jié)的增加十分敏感，當(dāng)傳輸距離大于1 000 m 時(shí)，信號(hào)易產(chǎn)生衰耗、畸變、群延時(shí)，易受干擾和噪聲積累而使接收端圖像質(zhì)量下降。

上海軌道交通1 號(hào)線(地鐵1 號(hào)線) 圖像采用光纖傳輸方式，各車站的視頻信號(hào)經(jīng)調(diào)頻調(diào)制后合成為一路復(fù)合信號(hào)，經(jīng)光纖、光發(fā)送器、光接收器完成圖像實(shí)時(shí)傳輸; 每4 個(gè)車站為一組占用一根光纖，控制信號(hào)經(jīng)PCM 通道傳送。這種傳輸方式由于車站攝像機(jī)數(shù)量多，控制中心輸出監(jiān)視器數(shù)目較少，采用傳統(tǒng)模擬視頻監(jiān)控方式以點(diǎn)對(duì)點(diǎn)進(jìn)行圖像傳輸時(shí)，大大增加了兩端的視頻調(diào)制和解調(diào)設(shè)備， 工程布線量極大，極不經(jīng)濟(jì)，且浪費(fèi)大量的帶寬。

而采用數(shù)字方式傳輸視頻信號(hào)則能克服模擬閉路電視圖像傳輸?shù)木窒扌?，其?yōu)點(diǎn)是:

(1) 可以多次再生中繼，不會(huì)因距離的增加而引起噪聲的積累;

(2) 采用數(shù)字壓縮編碼技術(shù)，使圖像信號(hào)在所需碼率以下，仍保持一定的圖像質(zhì)量;

(3) 采用數(shù)字的信道編碼技術(shù)，信號(hào)不易受干擾;

(4) 可以采用大規(guī)模集成電路，制成的設(shè)備體積小、成本低、可靠性高，易于調(diào)試維修。

2. 2 　3 號(hào)線數(shù)字圖像遠(yuǎn)程傳輸?shù)奶攸c(diǎn)

3 號(hào)線數(shù)字圖像遠(yuǎn)程傳輸通過ATM 寬帶異步傳輸方式，將車站的攝像機(jī)視頻信號(hào)轉(zhuǎn)化成數(shù)字壓縮信號(hào)傳輸至控制中心。其所采用的視頻壓縮標(biāo)準(zhǔn)是H. 261(ITU -T) ?？刂浦行母鶕?jù)各調(diào)度發(fā)出的控制切換信號(hào)將輸入的ATM 數(shù)字信號(hào)經(jīng)光纖傳輸分配到指定的8 臺(tái)監(jiān)視器上。由于視頻數(shù)據(jù)通信屬于實(shí)時(shí)傳輸，必須實(shí)時(shí)處理，如實(shí)時(shí)壓縮、解壓像傳輸時(shí)由于數(shù)碼率帶寬太高，必須盡量減少其速縮、傳輸和同步，故數(shù)字視頻遠(yuǎn)程監(jiān)控系統(tǒng)具有實(shí)率，并在重現(xiàn)時(shí)盡量保持圖像質(zhì)量，故必須對(duì)視頻時(shí)性、分布性和同步性的特點(diǎn)。其關(guān)鍵技術(shù)是視頻信號(hào)進(jìn)行壓縮。例如，可視電話的視頻信號(hào)不經(jīng)壓壓縮技術(shù)和ATM 圖像傳輸技術(shù)?？s，則需要140 MbitΠs 的速率，相當(dāng)于2 000 路數(shù)字

2. 2. 1 　視頻圖像編碼壓縮標(biāo)準(zhǔn)電話;如壓縮到64 kbitΠs 時(shí)，只相當(dāng)于1 路數(shù)字電視頻圖像具有真實(shí)、生動(dòng)、直觀的特點(diǎn)，但由于話。視頻信息量巨大，所占用的頻帶較寬，通常一路模目前常用的視頻編碼壓縮標(biāo)準(zhǔn)如表1 所示。擬彩色電視信號(hào)需占6 -8MHz 的模擬帶寬。在圖H. 261 是ITU -T 于1990 年通過的

表1 　常用的視頻編碼壓縮標(biāo)準(zhǔn)

“H. 261 3 64 kbitΠs 視聽業(yè)務(wù)用的視頻編解碼”標(biāo)準(zhǔn)，其中P = 1 ，2 ， ?，30 。它將圖像分解成非重疊的8 3 8 像素方塊，采用離散余弦變換的正交變換(DCT) 的方法，主要是通過減少每幀圖像時(shí)間上和空間上的冗余性和相關(guān)性信息來(lái)減少數(shù)據(jù)量。H. 261 適合在64～384 kbitΠs 的低帶寬下傳輸實(shí)時(shí)視頻圖像。

2. 2. 2 　ATM 異步傳輸模式

ATM 異步傳輸模式是由CCITT(ITU -T 前身) 提出的實(shí)現(xiàn)寬帶綜合業(yè)務(wù)數(shù)字網(wǎng)(B -ISDN) 的核心技術(shù)。它是分組交換和電路交換的結(jié)合，既有分組交換時(shí)線路利用率高的特點(diǎn)，又具有電路交換時(shí)快速交換的優(yōu)點(diǎn)。

ATM 不僅用于復(fù)用，也可用于交換。ATM 傳送的信息以信元為單位，時(shí)隙安排非常靈活，帶寬可動(dòng)態(tài)分配。ATM 的工作方式是面向連接的， 采用統(tǒng)計(jì)復(fù)用方式，帶寬將視當(dāng)前的要求在不同的用戶之間靈活分配，極大地提高了帶寬利用率; 同時(shí)能保障不同業(yè)務(wù)的服務(wù)質(zhì)量，如肯定的延遲，信息丟失率等。

在遠(yuǎn)程圖像監(jiān)控系統(tǒng)中，視頻業(yè)務(wù)需要高帶寬來(lái)保證圖像質(zhì)量，而ATM 技術(shù)完全能滿足通信系統(tǒng)對(duì)綜合業(yè)務(wù)承載以及服務(wù)質(zhì)量的要求。圖為ATM 允許對(duì)視頻用戶傳輸?shù)母鞣N業(yè)務(wù)按照CBR (固定比特率業(yè)務(wù)) 、VBR( 可變比特率業(yè)務(wù)) 、ABR (可用比特率業(yè)務(wù)) 以及UBR(未知比特率業(yè)務(wù)) 等進(jìn)行分類，對(duì)其服務(wù)質(zhì)量進(jìn)行分別設(shè)定和控制，而實(shí)時(shí)的視頻非常適合CBR 的業(yè)務(wù)類型。ATM 的這些技術(shù)特性，滿足了其在軌道交通遠(yuǎn)程圖像監(jiān)控系統(tǒng)中的應(yīng)用。

3 　3 號(hào)線遠(yuǎn)程圖像傳輸系統(tǒng)

3 號(hào)線共有19 個(gè)車站， 遠(yuǎn)程圖像傳輸采用ATM 異步傳輸方式，視頻壓縮方式為H. 261 標(biāo)準(zhǔn)。系統(tǒng)采用上海貝爾公司生產(chǎn)的基于DAS( 分布式ATM 變換) 技術(shù)的傳輸交換設(shè)備，主要由傳輸變換模式、視頻接入模塊和網(wǎng)管控制模塊組成。系統(tǒng)傳輸網(wǎng)絡(luò)拓?fù)鋱D詳見圖1 。

3. 1 　車站ATM 子系統(tǒng)

各車站分別設(shè)置DAS 機(jī)箱一個(gè)， 其中包括4 塊視頻輸入模塊DAS 405 和一塊ATM 傳輸交換模塊DAS 414 ， 詳見圖2 所示。

在車站，送往控制中心的模擬視頻(攝像機(jī)) 信號(hào)送入ATM 攝像機(jī)板DAS 405 的視頻輸入端，視頻接入模塊采用的是H. 261 編解碼設(shè)備。模擬視頻信號(hào)按H. 261 視頻壓縮標(biāo)準(zhǔn)轉(zhuǎn)換成數(shù)字信號(hào)并被壓縮，形成速率為64 kbitΠs 的碼流，然后這個(gè)視頻信號(hào)流被打包轉(zhuǎn)換為ATM 信號(hào)，接入ATM 傳輸交換網(wǎng)絡(luò)。其中板內(nèi)交換元件SE 提供通往ATM 底板的入口。控制信號(hào)通過RS 485 接口，經(jīng)解碼后可實(shí)現(xiàn) 頻輸入模塊DAS 406 、網(wǎng)絡(luò)控制模塊DAS 420 和攝像機(jī)及云臺(tái)的遠(yuǎn)程控制。 ATM 傳輸交換模塊DAS 414 。詳見圖3 所示。

3. 2 　控制中心ATM 系統(tǒng)

在控制中心設(shè)置DAS 機(jī)箱一個(gè)，其中包括視

圖1 　3 號(hào)線圖像傳輸系統(tǒng)網(wǎng)絡(luò)拓?fù)?/p>

圖2 　3 號(hào)線監(jiān)控系統(tǒng)車站網(wǎng)點(diǎn)配置圖

(1) ATM 信元流經(jīng)DAS 406 監(jiān)視器板上的SE 交換元件從復(fù)用狀態(tài)分解還原，ATM 信元被解包成壓縮視頻信號(hào)。此壓縮視頻信號(hào)流被實(shí)時(shí)解開， 被轉(zhuǎn)換成模擬視頻信號(hào)。監(jiān)視器板DAS 406 的功能是與攝像機(jī)板DAS 405 配合，共同進(jìn)行ATM 網(wǎng)絡(luò)上的視頻信號(hào)傳輸?shù)摹?/p>

(2) 傳輸交換模塊DAS 414 是系統(tǒng)的核心，它 能實(shí)現(xiàn)ATM 信元在雙向光纖155 MbitΠs SONETΠ SDH 線路上的插入和引出，并提供各種數(shù)字接口， 實(shí)現(xiàn)系統(tǒng)內(nèi)部連接以及節(jié)點(diǎn)之間的組網(wǎng)。使用一個(gè)STM -1 環(huán)網(wǎng)即可滿足傳輸帶寬的需要。ATM 接口在系統(tǒng)底板處提供一個(gè)雙向、連續(xù)的信元流。所有的控制、監(jiān)控和配置均通過ATM 反向通路由所謂的“ForeMe”ATM 信元執(zhí)行，無(wú)需額外的控制總線接口。 議處理功能、信令功能和網(wǎng)絡(luò)管理功能等各項(xiàng)功傳輸交換模塊可實(shí)現(xiàn)交換功能、連接功能、監(jiān) 能。視統(tǒng)計(jì)功能、流量控制功能、擁塞控制功能、高層協(xié)

圖3 　3 號(hào)線監(jiān)控系統(tǒng)控制中心網(wǎng)點(diǎn)配置圖

CCR 各位調(diào)度員通過控制鍵盤發(fā)出控制信號(hào)， 串行控制流經(jīng)RS 485 接口送入所選車站的目標(biāo)攝像機(jī)工作板上的攝像機(jī)控制接口，經(jīng)解碼后控制目標(biāo)攝橡機(jī)及云臺(tái);在控制中心，視頻碼流經(jīng)過視頻輸出模塊被還原，并被轉(zhuǎn)換成模擬視頻信號(hào)，通過監(jiān)視器輸出，從而實(shí)現(xiàn)攝像機(jī)及云臺(tái)的遠(yuǎn)程監(jiān)控。

3. 3 　ATM 網(wǎng)管控制系統(tǒng)

ATM 綜合傳輸系統(tǒng)的系統(tǒng)配置和狀態(tài)監(jiān)視由網(wǎng)管控制臺(tái)實(shí)現(xiàn)。外部網(wǎng)管接口使AAL5ΠIPΠOSIΠCMIP 標(biāo)準(zhǔn)協(xié)議。網(wǎng)絡(luò)控制板DAS 420 是一個(gè)以PC 機(jī)為基礎(chǔ)的平臺(tái)，通過DAS 420 的ATM 底板接口可傳送和接收ATM 信元及AAL5 適配層的幀，來(lái)直接實(shí)施網(wǎng)絡(luò)的接入?；赪indows 的網(wǎng)管軟件與其共同完成整個(gè)網(wǎng)絡(luò)的實(shí)時(shí)管理和狀態(tài)監(jiān)視。系統(tǒng)還提供電子地圖，供控制人員任意調(diào)看各車站的攝像機(jī)畫面顯示在指定的監(jiān)視器上，進(jìn)行圖像自動(dòng)循環(huán)掃描及模擬控制鍵盤對(duì)遠(yuǎn)程攝像機(jī)進(jìn)行遙控。

4 　結(jié)論和建議

(1) 采用ATM 進(jìn)行數(shù)字視頻傳輸，充分發(fā)揮了其按需分配帶寬、按需連接的特點(diǎn)，只有控制中心調(diào)看圖像時(shí)，才占用傳輸帶寬。因此，視頻傳輸所需的帶寬僅與控制中心監(jiān)視器的數(shù)量有關(guān)，而與攝像機(jī)數(shù)目無(wú)關(guān)。即大量的攝像機(jī)信號(hào)并不消耗帶寬，在保證圖像質(zhì)量的情況下，能大大節(jié)省帶寬資源，并為今后系統(tǒng)的擴(kuò)展和升級(jí)留有較多的余量。

(2) 由于采用數(shù)字視頻壓縮技術(shù)，模擬視頻信號(hào)經(jīng)壓縮后速率大大降低，極大地提高了頻帶寬度利用率，而且能夠同時(shí)保持實(shí)時(shí)電視監(jiān)視系統(tǒng)的低等待時(shí)間和高質(zhì)量。由于3 號(hào)線采用的H. 261 標(biāo)準(zhǔn)屬第一代視頻壓縮算法，適于在64～384 kbitΠs 的低帶寬下實(shí)時(shí)圖像傳輸，圖像質(zhì)量有待提高; 而新一代的MPEG-2 壓縮標(biāo)準(zhǔn)能保證在幾乎感覺不到質(zhì)量損失的情況下， 將視頻傳輸速率降低到4 MbitΠs ， 具有出色的圖像品質(zhì)。MPEG-2 可以在保證在ATM 上傳送的大型、高速視頻流完整性的同時(shí)，消除技術(shù)障礙。未來(lái)的上海軌道交通5 號(hào)線(莘閔線) 數(shù)字圖像傳輸系統(tǒng)即采用MPEG-2 壓縮標(biāo)準(zhǔn)。

(3)ATM 結(jié)構(gòu)簡(jiǎn)單靈活，支持各種帶寬通信網(wǎng)絡(luò)，能把網(wǎng)絡(luò)中所有的信息集中到幾個(gè)中央控制室。通過不同網(wǎng)絡(luò)中傳輸?shù)囊曨l、音頻和數(shù)據(jù)，對(duì)系統(tǒng)各個(gè)部分資源進(jìn)行控制和管理， 實(shí)現(xiàn)資源共享。

參　考　文　獻(xiàn)

篇8

為適應(yīng)這一新的發(fā)展方向，數(shù)字視頻網(wǎng)絡(luò)的領(lǐng)先提供商BigBand Networks日前宣布推出一款融合視頻交換(CVEx)平臺(tái)，這種智能軟件控制平臺(tái)提供了一種通過網(wǎng)絡(luò)邊緣向傳統(tǒng)MPEG機(jī)頂盒(STB)以及下一代IP設(shè)備上傳送并管理線性和非線性視頻服務(wù)的統(tǒng)一方案。旨在滿足服務(wù)提供商對(duì)融合視頻傳送的需求，提高頻譜效率，在滿足當(dāng)前如高標(biāo)清同播這樣的應(yīng)用需求的同時(shí)，也為向未來(lái)的融合網(wǎng)絡(luò)過渡提供了理想的發(fā)展道路。

CVEx平臺(tái)是業(yè)界第一個(gè)解決了RF視頻服務(wù)和IP視頻服務(wù)這兩個(gè)完全不同類型視頻服務(wù)統(tǒng)一管理問題的平臺(tái)，它通過一個(gè)獨(dú)立的帶寬分配池動(dòng)態(tài)分配資源給不同類型的視頻服務(wù)，同時(shí)提供查看服務(wù)使用和資源利用情況的可視化界面。運(yùn)營(yíng)商正在逐步取消用于個(gè)人服務(wù)的專用帶寬，如視頻點(diǎn)播(VOD)、交換數(shù)字視頻(SDV)和IPTV，該軟件恰好可以提供一個(gè)統(tǒng)一控制平臺(tái)，并同步提高頻譜利用率。CVEx可支持多種行業(yè)標(biāo)準(zhǔn)協(xié)議和第三方應(yīng)用接口，并且支持與CMTS架構(gòu)的集成。

在融合視頻環(huán)境中，部署統(tǒng)一的控制平面將滿足多播和單播會(huì)話請(qǐng)求所需的高傳輸率和快速響應(yīng)需求。隨著運(yùn)營(yíng)商不斷增加服務(wù)并采用網(wǎng)絡(luò)機(jī)頂盒指南功能，性能、可靠性和冗余性將變得日益重要。BigBand Networks提供的全冗余會(huì)話管理器可以滿足SDV極高會(huì)話處理率的需求。這使得BigBand Networks處于行業(yè)領(lǐng)先地位，也為提供CVEx做好了充分準(zhǔn)備。目前，BigBand解決方案每年在超過2400萬(wàn)戶家庭進(jìn)行數(shù)十億次實(shí)時(shí)處理。

BigBand Networks公司首席運(yùn)營(yíng)官David W. Heard指出：“向無(wú)縫傳送視頻至多個(gè)網(wǎng)絡(luò)的下一代網(wǎng)絡(luò)過渡帶來(lái)了更多復(fù)雜性。通過我們的智能軟件控制平面將視頻統(tǒng)一起來(lái)，CVEx有助于將目前的架構(gòu)轉(zhuǎn)變成一個(gè)真正的融合視頻解決方案，傳送給任意設(shè)備。因此，將來(lái)不管是有線還是無(wú)線，傳統(tǒng)的或下一代IP都不是問題。我們的工作就是為我們的客戶提供一個(gè)更加簡(jiǎn)單靈活的視頻傳輸解決方案。隨時(shí)隨地為多種設(shè)備提供高質(zhì)量的視頻體驗(yàn)。”

融合視頻傳送方式可滿足市場(chǎng)需求

運(yùn)營(yíng)商希望進(jìn)一步發(fā)展他們的網(wǎng)絡(luò)，從而以高性能和高可靠性實(shí)現(xiàn)向多種終端快速無(wú)縫傳送現(xiàn)有的和特殊需求的服務(wù)。CVEx將為多播和單播服務(wù)創(chuàng)建一個(gè)視頻一體化戰(zhàn)略，以支持融合視頻傳送發(fā)展戰(zhàn)略。

CVEx平臺(tái)具有以下全新特性：

提供一個(gè)通用界面和單一方案，實(shí)現(xiàn)快速部署并確保在傳統(tǒng)的MPEG機(jī)頂盒和下一代IP設(shè)備上實(shí)現(xiàn)高質(zhì)量視頻服務(wù)體驗(yàn)。這些設(shè)備包括個(gè)人電腦、電視機(jī)乃至移動(dòng)設(shè)備；

可按需對(duì)帶寬資源進(jìn)行會(huì)聚并重新分配；

提供用戶和視頻服務(wù)考量工具，在多個(gè)數(shù)據(jù)平面提供對(duì)節(jié)目和服務(wù)行為、網(wǎng)絡(luò)資源使用情況和“假設(shè)”情景規(guī)劃的全面可視化界面。

篇9

【關(guān)鍵詞】 Android 視頻文件 傳輸 處理

一、視頻自適應(yīng)算法框架

基于Android視頻文件傳輸?shù)淖赃m應(yīng)算法是根據(jù)網(wǎng)絡(luò)環(huán)境下傳輸實(shí)時(shí)視頻數(shù)據(jù)而提出的一種算法[1]。在進(jìn)行視屏文件傳輸時(shí)，通過對(duì)網(wǎng)絡(luò)進(jìn)行探測(cè)以及對(duì)反饋信息的分析二實(shí)現(xiàn)基于Android視頻傳輸?shù)淖赃m應(yīng)控制，該自適應(yīng)算法的實(shí)現(xiàn)主要從4個(gè)方面進(jìn)行：（1）Android系統(tǒng)接受包含視頻數(shù)據(jù)的時(shí)間戳、發(fā)送序號(hào)、狀態(tài)值等網(wǎng)絡(luò)信息的視頻數(shù)據(jù)，參考實(shí)時(shí)傳輸協(xié)議RTP進(jìn)行打包傳輸。（2）Android系統(tǒng)在接受到視頻數(shù)據(jù)包之后，通過解包獲取數(shù)據(jù)信息以及當(dāng)前的網(wǎng)絡(luò)狀態(tài)，并反饋控制策略，同時(shí)計(jì)算數(shù)據(jù)包的丟失率以及帶寬瓶頸等參數(shù)，然后參考實(shí)時(shí)參數(shù)協(xié)議RTCP進(jìn)行打包然后反饋給視頻數(shù)據(jù)的發(fā)送端。（3）Android系統(tǒng)通過利用TCP友好速率控制算法來(lái)計(jì)算網(wǎng)絡(luò)的實(shí)時(shí)帶寬，然后利用視頻自適應(yīng)算法來(lái)實(shí)現(xiàn)平滑的視頻數(shù)據(jù)傳輸，降低TCP的AIMD算法所帶來(lái)的帶寬波動(dòng)。（4）Android系統(tǒng)根據(jù)調(diào)整以后的數(shù)據(jù)接收速率對(duì)視頻數(shù)據(jù)包進(jìn)行接收。

基于Android視頻傳輸?shù)淖赃m應(yīng)算法首先要根據(jù)接收的新型進(jìn)行RTCP分析，病對(duì)分組丟失的統(tǒng)計(jì)規(guī)律、分組延遲抖動(dòng)以及信息傳輸所消耗的時(shí)間進(jìn)行計(jì)算，然后對(duì)網(wǎng)絡(luò)狀態(tài)進(jìn)行估計(jì)以判斷是否需要對(duì)帶寬進(jìn)行調(diào)整。另外還要根據(jù)當(dāng)前網(wǎng)絡(luò)的狀況對(duì)視頻傳輸?shù)膸掃M(jìn)行適當(dāng)?shù)恼{(diào)整。

二、TFRC算法

TCP友好速率控制算法能夠根據(jù)網(wǎng)絡(luò)狀態(tài)對(duì)數(shù)據(jù)流速率進(jìn)行調(diào)整，實(shí)現(xiàn)控制網(wǎng)絡(luò)擁塞狀況的目的，它是基于速率的擁塞控制算法。TFRC吞吐量變化較為穩(wěn)定，波動(dòng)較小，主要適用于電話、流媒體等對(duì)信號(hào)傳輸穩(wěn)定性要求較高的應(yīng)用。TFRC算法的基礎(chǔ)是TCP穩(wěn)態(tài)速率模型，該模型給出了TCP在網(wǎng)絡(luò)處于擁塞避免階段時(shí)的跑平均發(fā)送速率。

TFRC穩(wěn)態(tài)速率公式如下：

上面公式中的s代表TCP報(bào)文的大??；p是包的丟失率；t0是數(shù)據(jù)報(bào)文超時(shí)時(shí)間；tRTT是數(shù)據(jù)報(bào)文環(huán)路時(shí)間；b表示一個(gè)應(yīng)答所接收到的報(bào)文數(shù)量。通過該公式能夠計(jì)算出傳輸數(shù)據(jù)流的穩(wěn)態(tài)接收速率B（p）。

從上面的公式能夠看出對(duì)傳輸數(shù)據(jù)流的穩(wěn)態(tài)接收速率影響最大的是數(shù)據(jù)包的丟失率。數(shù)據(jù)包的丟失率主要分為3個(gè)步驟，分別為初始化參數(shù)列表，丟失率的判斷以及丟失率的計(jì)算。

三、基于Android平臺(tái)的視頻自適應(yīng)傳輸算法

考慮到目前Android智能手機(jī)的性能以及網(wǎng)絡(luò)狀況，視頻自適應(yīng)算法通過將TFRC算法以及視頻編碼算法結(jié)合，實(shí)現(xiàn)視屏編碼的動(dòng)態(tài)調(diào)整和發(fā)送。當(dāng)發(fā)現(xiàn)當(dāng)前網(wǎng)絡(luò)出現(xiàn)擁塞后，Android系統(tǒng)會(huì)對(duì)視頻數(shù)據(jù)的接受策略進(jìn)行自動(dòng)調(diào)整，保證視頻傳輸?shù)姆€(wěn)定性[2]。如果網(wǎng)絡(luò)出現(xiàn)長(zhǎng)時(shí)間的擁塞，視頻自適應(yīng)算法的表現(xiàn)就是在最初階段出現(xiàn)較大的丟包率，隨后通過算法的調(diào)整，逐漸適應(yīng)網(wǎng)絡(luò)擁塞的環(huán)境，丟包率也會(huì)逐漸降低，保證視頻傳輸?shù)牧鲿承浴?/p>

通過與TCP基于AIMD窗口控制算法相比較，視頻自適應(yīng)算法采用了更為緩和的速率變化控制策略，既降低與TCP流之間的影響，又使數(shù)據(jù)傳輸速率變得更加穩(wěn)定，有效的實(shí)現(xiàn)了視頻文件的穩(wěn)定傳輸，同時(shí)還保證了視頻的傳輸質(zhì)量。

四、總結(jié)

本文提出了一種基于Android智能手機(jī)視頻傳輸?shù)淖赃m應(yīng)算法，該算法能夠?qū)W(wǎng)絡(luò)帶寬進(jìn)行實(shí)時(shí)動(dòng)態(tài)探測(cè)，自動(dòng)適應(yīng)當(dāng)前的網(wǎng)絡(luò)擁塞狀況，并通過利用TFRC算法制定出平滑的數(shù)據(jù)傳輸帶寬，根據(jù)實(shí)時(shí)的帶寬對(duì)視頻的編碼以及傳輸速率進(jìn)行控制，有效的提高了視頻文件的傳輸質(zhì)量，改善用戶的使用體驗(yàn)，該自適應(yīng)算法具有較高的應(yīng)用價(jià)值。

參 考 文 獻(xiàn)

篇10

關(guān)鍵詞：HDMI；硬件編碼；無(wú)線傳輸；H264

中圖分類號(hào)：TN926+.24；TP393 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：2095-1302（2017）01-00-03

0 引 言

在當(dāng)前物聯(lián)網(wǎng)技術(shù)浪潮的推動(dòng)下，物與物相連的需求快速增長(zhǎng)，而多媒體信息特別是視頻信息因其數(shù)據(jù)量大的特點(diǎn)，一直是通信領(lǐng)域的研究熱點(diǎn)。在應(yīng)用方面，智能家居、智能會(huì)議室、智能教學(xué)等系統(tǒng)得到了不斷推廣，而音視頻的局域網(wǎng)內(nèi)傳輸技術(shù)始終扮演著智能系統(tǒng)的重要角色。雖然傳統(tǒng)的有線傳輸方式能提供高質(zhì)量的音視頻傳輸效果，但在實(shí)際應(yīng)用中人們常常囿于布線困難，因而提出無(wú)線傳輸?shù)男枨?。目前，市?chǎng)上的音頻無(wú)線傳輸方案已經(jīng)相對(duì)成熟，其媒介選擇有U段無(wú)線、WiFi、藍(lán)牙等。相比而言，無(wú)線視頻的發(fā)展相對(duì)緩慢，因?yàn)槠溟_發(fā)難度和開發(fā)成本都相對(duì)較大。盡管如此，無(wú)線視頻的需求依然是市場(chǎng)的熱點(diǎn)。比如安防專用的攝像頭無(wú)線監(jiān)控系統(tǒng)，拍攝專用的無(wú)人機(jī)拍攝無(wú)線傳輸系統(tǒng)，教學(xué)或會(huì)議專用的無(wú)線視頻投影應(yīng)用等。

無(wú)線視頻傳輸應(yīng)用中的視頻源和接收端在不同場(chǎng)景中各有不同。例如教學(xué)或會(huì)議中的無(wú)線投影，其視頻源可來(lái)自個(gè)人電腦的HDMI輸出或VGA輸出，接收端則一般是投影儀的HDMI端口或VGA端口。由于HDMI標(biāo)準(zhǔn)對(duì)高清視頻的支持較好，因此在高質(zhì)量視頻傳輸中，研究HDMI視頻流的無(wú)線傳輸方案具有很好的應(yīng)用價(jià)值。

對(duì)于視頻數(shù)據(jù)，未經(jīng)壓縮的原始視頻數(shù)據(jù)量是無(wú)線傳輸難以承受的，尤其對(duì)于高清晰度視頻，大數(shù)據(jù)量的無(wú)線傳輸將導(dǎo)致系統(tǒng)傳輸方案的成本大大增加[1]。因此對(duì)HDMI視頻流的無(wú)線傳輸必須引入合適的編碼方案，平衡編碼效果和無(wú)線通信容量之間的矛盾，達(dá)到低延時(shí)的播放效果[2]。為解決上述問題，本文采用S5PV210處理器，以ADV7611接收HDMI視頻流，然后通過硬件編碼器進(jìn)行視頻編碼，再由處理器打包無(wú)線發(fā)送；接收端接收到視頻數(shù)據(jù)后解碼視頻，并由HDMI接口輸出。

1 系統(tǒng)整體硬件方案設(shè)計(jì)

圖 1所示為高清視頻無(wú)線傳輸?shù)南到y(tǒng)原理及實(shí)現(xiàn)結(jié)構(gòu)圖。系統(tǒng)分為發(fā)送端和接收端兩部分，這兩部分是獨(dú)立的系統(tǒng)，可以使用一個(gè)發(fā)送端和一個(gè)接收端進(jìn)行一對(duì)一工作，也可以使用一個(gè)發(fā)送端和多個(gè)接收端同時(shí)工作，或者多個(gè)發(fā)送端和一個(gè)接收端分時(shí)連接工作，這些都可以在軟件應(yīng)用層實(shí)現(xiàn)。底層的編解碼和無(wú)線通信架構(gòu)相同，為了描述方便，在此以一個(gè)發(fā)送端對(duì)一個(gè)接收端作為描述實(shí)例。

由圖1可知，發(fā)送端包括視頻接收前端模塊和編碼發(fā)送模塊。視頻接收前端主要由ADV7611實(shí)現(xiàn)HDMI視頻流的輸入，并將視頻數(shù)據(jù)轉(zhuǎn)為YCbCr信號(hào)，通過板上總線傳輸?shù)骄幋a發(fā)送模塊。編碼發(fā)送模塊主要是S5PV210處理器，通過處理器內(nèi)部的多格式編解碼器（Multi Format Codec，MFC）對(duì)視頻進(jìn)行壓縮。壓縮后的視頻由RTP協(xié)議發(fā)送，通過物理層WiFi實(shí)時(shí)傳輸?shù)浇邮斩薣3]。解碼端將視頻流解碼，獲取LCD設(shè)備的緩存區(qū)視頻流數(shù)據(jù)，將HDMI流以HDMI流媒體的形式輸出。

在應(yīng)用方面，上述系統(tǒng)的發(fā)送端通過HDMI接口接收電腦或視頻播放器等視頻源的輸出，而接收端也通過HDMI接口連接投影儀或顯示器等設(shè)備，實(shí)現(xiàn)HDMI視頻流的無(wú)線傳輸。

2 系統(tǒng)軟件設(shè)計(jì)

2.1 系統(tǒng)配置

系統(tǒng)配置包含Linux系統(tǒng)內(nèi)核配置與對(duì)ADV7611的配置。根據(jù)系統(tǒng)需求，ADV7611與S5PV210之間以ITU601的格式傳輸視頻數(shù)據(jù)，因此在Linux內(nèi)核中需要修改視頻輸入驅(qū)動(dòng)為ITU601格式，并設(shè)置好YCbCr數(shù)據(jù)的順序格式，例如CbYCrY等。這兩個(gè)參數(shù)在內(nèi)核中的結(jié)構(gòu)體s2c_platform_camera定義。對(duì)ADV7611的寄存器配置則是在應(yīng)用程序中通過I2C驅(qū)動(dòng)實(shí)現(xiàn)，具體參數(shù)可根據(jù)需求按芯片文檔說(shuō)明設(shè)定。

2.2 視頻編碼

為了實(shí)現(xiàn)大數(shù)據(jù)量高清視頻的無(wú)線傳輸，平衡視頻效果和無(wú)線通信容量之間的矛盾，系統(tǒng)對(duì)HDMI接收器得到的視頻流進(jìn)行實(shí)時(shí)壓縮，通過減少和去除冗余視頻數(shù)據(jù)的方式，達(dá)到可靠發(fā)送的目的[4]。為了達(dá)到低延時(shí)的播放效果，可以充分利用S5PV210中集成的MFC硬件編碼模塊，以減輕處理器的計(jì)算量。MFC是ARM微處理器內(nèi)部一種支持多種硬件編碼方式的硬件電路，視頻編碼支持 MPEG-4、H.263以及H.264，分辨率可達(dá)到1 080P@30fps。本文選用H.264的編碼方式。

圖 2所示為MFC硬件編碼流程圖。MFC硬件編碼在程序?qū)崿F(xiàn)中定義了三個(gè)函數(shù)，分別為初始化函數(shù)，執(zhí)行函數(shù)和句柄放函數(shù)，利用這三個(gè)函數(shù)即可實(shí)現(xiàn)整套編碼操作。初始化函數(shù)的作用是對(duì)整個(gè)MFC的參數(shù)進(jìn)行設(shè)置。打開設(shè)備節(jié)點(diǎn)，進(jìn)行內(nèi)存到應(yīng)用的內(nèi)存映射，初始化關(guān)于MFC設(shè)備的結(jié)構(gòu)體，并提供相應(yīng)的參數(shù)，把_MFCLIB_H264_ENC參數(shù)傳入MFC跟深層次的結(jié)構(gòu)體當(dāng)中，通過ioctl函數(shù)把參數(shù)傳入內(nèi)核。

初始化MFC之后讀取視頻流，得到輸入圖像的地址緩沖指針，等待緩沖區(qū)成像數(shù)據(jù)。成像后讀取一幀視頻數(shù)據(jù)，并將這一幀數(shù)據(jù)放入MFC編碼，第一次的編碼需要傳入配置參數(shù)。編碼完成后得到H.264編碼格式的網(wǎng)絡(luò)提取層（Network Abstraction Layer，NAL）數(shù)據(jù)。因?yàn)橄到y(tǒng)采用RTP協(xié)議進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)傳輸，對(duì)于一幀圖像的NAL數(shù)據(jù)需要根據(jù)RTP網(wǎng)絡(luò)數(shù)據(jù)的幀長(zhǎng)度進(jìn)行分片，分片后的視頻數(shù)據(jù)添加載荷頭FU-A打包，添加RTP包頭并向客戶端發(fā)送一幀視頻數(shù)據(jù)。之后系統(tǒng)重新讀取一幀視頻數(shù)據(jù)再進(jìn)行MFC編碼。

為了方便描述沒有顯示編碼過程的退出機(jī)制，實(shí)際程序中根據(jù)具體需求以合適的方式退出編碼，釋放句柄，解除映射。

2.3 無(wú)線傳輸

編碼后的視頻以RTP協(xié)議在局域網(wǎng)傳輸。為了實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)或點(diǎn)對(duì)多點(diǎn)的視頻傳輸，發(fā)送端利用WiFi網(wǎng)卡實(shí)現(xiàn)軟接入點(diǎn)的功能。因此多個(gè)接收端可以同時(shí)連接到發(fā)送端的接入點(diǎn)，從而訪問RTP服務(wù)獲得視頻數(shù)據(jù)。對(duì)于多個(gè)發(fā)送端對(duì)一個(gè)接收端的情況，可以設(shè)定接收端為WiFi接入點(diǎn)，發(fā)送端連接到接收端再進(jìn)行數(shù)據(jù)傳輸，但是在應(yīng)用中各發(fā)送端只能以時(shí)分復(fù)用的形式將數(shù)據(jù)發(fā)送到接收端。

2.4 視頻解碼

解碼器對(duì)發(fā)送來(lái)的H.264等壓縮格式的視頻數(shù)據(jù)包進(jìn)行實(shí)時(shí)解碼，通過采用相應(yīng)的解壓縮算法還原視頻的高清晰度，轉(zhuǎn)化為可播放的非壓縮視頻流格式。FFMPEG是一個(gè)集音視頻編解碼在內(nèi)的多種功能為一體的開源解決方案，支持H.264在內(nèi)的40多種編碼和70多種解碼[5]。解碼端利用FFMPEG旖飴耄主要涉及l(fā)ibavcodec庫(kù)、libswscale庫(kù)和libavformat庫(kù)[6]。視頻數(shù)據(jù)流解碼流程：由ByteIOContext表示的廣義輸入文件，在AVStream提供的特定文件容器流信息的指引下，用AVInputFormat接口的read_packet（）函數(shù)讀取完整的一幀數(shù)據(jù)，分別放到音頻或視頻PacketQueue隊(duì)列中，這部分功能由獨(dú)立的解碼線程完成。對(duì)于視頻數(shù)據(jù)，視頻處理線程不停從視頻PacketQueue 隊(duì)列中取出視頻幀，調(diào)用AVCodec接口的decode（）函數(shù)解碼視頻幀，在適當(dāng)延時(shí)后做顏色空間轉(zhuǎn)化并調(diào)用顯示輸出函數(shù)庫(kù)顯示出來(lái)。

3 功能測(cè)試

為了驗(yàn)證系統(tǒng)的功能和效果，本節(jié)搭建一發(fā)一收的演示系統(tǒng)，其實(shí)物圖如圖3所示。

發(fā)送端由ADV7611的視頻前端測(cè)試板接收筆記本電腦輸出的HDMI視頻流，然后通過ITU-R.BT601標(biāo)準(zhǔn)接口將轉(zhuǎn)碼得到的YCbCr數(shù)據(jù)傳輸?shù)絊5PV210開發(fā)板進(jìn)行硬件編碼。發(fā)送端S5PV210開發(fā)板配置了WiFi的軟接入點(diǎn)，并與接收端建立無(wú)線連接，同時(shí)開啟視頻RTP傳輸服務(wù)，支持編碼后的視頻數(shù)據(jù)發(fā)送服務(wù)。

接收端硬件只需提供WiFi網(wǎng)卡和HDMI視頻輸出接口。接收端處理器通過網(wǎng)卡連接到發(fā)送端接入點(diǎn)，然后由RTP客戶端軟件獲取發(fā)送端的視頻數(shù)據(jù)，將視頻數(shù)據(jù)解碼后由HDMI接口輸出。

由圖3可知，筆記本電腦直接復(fù)制屏幕并輸出到HDMI接口；HDMI接口的視頻流輸入發(fā)送端S5PV210開發(fā)板；S5PV210開發(fā)板將視頻壓縮編碼后通過無(wú)線連接發(fā)送給接收端；接收端將視頻解碼輸出到HDMI接口，并最終輸出到顯示器顯示。

4 結(jié) 語(yǔ)

本文針對(duì)HDMI視頻流給出了一種無(wú)線視頻傳輸系統(tǒng)的設(shè)計(jì)方案。該方案將傳輸系統(tǒng)分為發(fā)送端和接收端兩個(gè)獨(dú)立模塊，可以靈活配置為一發(fā)一收、一發(fā)多收、多發(fā)一收等應(yīng)用場(chǎng)景。系統(tǒng)采用硬件編碼的方式實(shí)現(xiàn)了在無(wú)線傳輸條件下的視頻清晰度和視頻傳輸延時(shí)的優(yōu)化。針對(duì)該方案，可以從進(jìn)一步提高視頻清晰度著手，因?yàn)镾5PV210的硬件編碼模塊在1 080P的輸入分辨率時(shí)最高支持的幀率為30 fps，而很多高清視頻源可達(dá)50/60 fps。因此可以在幀率提高方面進(jìn)行研究，或?qū)Ω叻直媛嗜? 160 P的視頻處理進(jìn)行研究。

參考文獻(xiàn)

[1]馬思偉.AVS視頻編碼標(biāo)準(zhǔn)技術(shù)回顧及最新進(jìn)展[J].計(jì)算機(jī)研究與發(fā)展，2015，52 （1）：27-37.

[2]CHIEN S Y， HUANG Y W， CHEN C Y， et al. Hardware architecture design of video compression for multimedia communication systems[J]. IEEE Communications Magazine， 2005， 43（8）： 122-131.

[3]胡東，黃辰，朱文杰，等.基于H264的智能家居視頻監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].物聯(lián)網(wǎng)技術(shù)，2016，6（2）：25-26.

[4]樊曉平，熊哲源，陳志杰，等.無(wú)線多媒體傳感器網(wǎng)絡(luò)視頻編碼研究[J].通信學(xué)報(bào)，2011，32（9）：137-146.

[5]楊德偉，易善強(qiáng)，王華.基于ARM和WiFi的無(wú)線視頻傳輸實(shí)驗(yàn)系統(tǒng)[J].實(shí)驗(yàn)室研究與探索，2014，33（10）：156-161.

[6]王剛，毛劍飛，田青，等.基于ARM11的無(wú)線視頻監(jiān)控系統(tǒng)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2011，20 （8）：18-22.