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

篇1

依據(jù)產品系列的分類，主會場分為 五個大區(qū)。

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

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

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

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

篇2

【關鍵詞】互聯(lián)網；若干視頻傳輸；關鍵技術分析

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

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

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

2互聯(lián)網的若干視頻傳輸關鍵技術研究

2.1面向信道編碼的糾錯技術分析

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

2.2自適應遺傳算法的糾錯方法

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

2.3對擁塞控制的視頻組播傳輸技術進行分析

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

2.4對視覺感知的碼率控制方法分析

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

2.5對SMDP單播擁塞控制方法進行分析

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

3結束語

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

參考文獻

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

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

[3]程振宇，張燦，和智濤，等.基于3G網絡視頻傳輸?shù)囊环NQoS控制方法[J].中國科學院大學學報，2014，31（1）：117~123.

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

篇3

關鍵詞：實時傳輸協(xié)議；實時傳輸控制協(xié)議；視頻傳輸

中圖分類號：TP393 文獻標識碼：A文章編號：1009-3044(2007)04-10969-02

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）接收算法

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

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

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

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

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

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

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

③在RTP層經過解包，去掉RTP報文頭；

④送給上層播放；

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

4 結束語

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

參考文獻：

[1]Anthony Jones, Jim Ohlund.網絡編程技術[M].北京：機械工業(yè)出版社，2000.

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

[3][美]斯坦伯姆著，曾華深等譯. 計算機網絡（第二版）[M].成都：成都科技大學出版社，1989.

篇4

相關技術簡介

1　雙絞線技術

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

2　互導型放大器

互導型放大器(又稱跨導型放大器)的輸入信號是電壓量，輸出信號是電流量，其增益稱為互導Gm。互導型放大器是一種電壓／電流模式混合電路，由于其內部只有電壓――電流變換級和電流傳輸級，而沒有電壓傳輸級，因此沒有大擺幅電壓信號和密勒倍增效應，從而具有頻帶寬、高頻性能好及大信號轉換速度高等特性?；头糯笃鞯碾娐方Y構簡單，電源電壓和功耗均得到了降低。

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

3　MAX435和MAX436

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

設計與實現(xiàn)方法

1　電路設計

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

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

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

2　測試結果

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

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

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

結論

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

篇5

【關鍵詞】802.11；視頻傳輸；服務質量；包調度

1.引言

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

2.相關研究

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

3.視頻包的失真估計

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

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

4.包調度算法

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

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

此時，隊列中所有視頻包總的傳輸失真可以表示為：

（1）

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

（2）

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

（3）

設表示隊列長度的平均值，且E{L|L>1} ≈。把公式（3）代入（2）有：

（4）

篇6

關鍵詞：FMS 跨平臺 RTMP ffmpeg HLS

中圖分類號：TN919.8 文獻標識碼：A 文章編號：1007-9416（2016）11-0106-02

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

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

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

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

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

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

PC端運用Flex結合FMS實現(xiàn)視頻點播、直播的關鍵代碼如下：

2.1 點播服務器上的視頻文件

nc.connect（"rtmp：// FMS服務器IP地址：端口號/PlayStreams路徑"）；//連接FMS

ns=new NetStream（nc）；

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

2.2 向服務器推流，用于直播

nc.connect（"rtmp：//FMS服務器IP地址：端口號/LiveStreams路徑"）；//連接FMS

ns=new NetStream（nc）；

ns.attachCamera（cam）；//調用攝像頭

ns.attachAudio（mic）；//調用麥克風

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

2.3 播放直播流

nc.connect（"rtmp：//FMS服務器IP地址：端口號/LiveStreams路徑"）；//連接FMS

ns=new NetStream（nc）；

ns.play（"視頻流名稱"）；//對應于視頻流端的publish（"視頻流名稱"，"live"）.

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

3 移動端實現(xiàn)視頻

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

3.1 ffmpeg推流

ffmpeg實現(xiàn)視頻推流首先需指定協(xié)議，然后向服務器寫入視頻數(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類型結構體， out_filename為FMS服務器地址，型如 rtmp：//0.0.0.0/…/livestream。

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

3.2 ffmepg在android上的移植

ffmpeg用C語言編寫，在android平臺中使用，需先編譯成.so文件，然后通過JNI（Java Native Interface）調用，JNI技術允許Java代碼和其他語言寫的代碼（C&C++）進行交互。

編譯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文件和頭文件導入自己的工程中，并編寫自己的C文件調用相關功能，然后配置安卓makefile文件Android.mk。在java程序中使用native？functionname（…）；格式調用C文件中自己編寫的函數(shù)。

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

3.3.1 在mac os下使用ffmpeg

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

3.3.2 編譯在iOS下使用的ffmpeg library庫 .m文件中調用

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

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

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

4 移動端視頻播放

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

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

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

5 結語

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

參考文獻

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

[2]劉仕坤.手機平臺JavaScript語言解釋器設計與實現(xiàn)[D].中南大學，2009.

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

篇7

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

1 　引言

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

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

2 　3 號線數(shù)字圖像遠程傳輸?shù)奶攸c

2. 1 　不同的圖像傳輸方式的特點

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

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

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

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

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

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

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

2. 2 　3 號線數(shù)字圖像遠程傳輸?shù)奶攸c

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

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

表1 　常用的視頻編碼壓縮標準

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

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

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

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

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

3 　3 號線遠程圖像傳輸系統(tǒng)

3 號線共有19 個車站， 遠程圖像傳輸采用ATM 異步傳輸方式，視頻壓縮方式為H. 261 標準。系統(tǒng)采用上海貝爾公司生產的基于DAS( 分布式ATM 變換) 技術的傳輸交換設備，主要由傳輸變換模式、視頻接入模塊和網管控制模塊組成。系統(tǒng)傳輸網絡拓撲圖詳見圖1 。

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

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

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

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

在控制中心設置DAS 機箱一個，其中包括視

圖1 　3 號線圖像傳輸系統(tǒng)網絡拓撲

圖2 　3 號線監(jiān)控系統(tǒng)車站網點配置圖

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

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

圖3 　3 號線監(jiān)控系統(tǒng)控制中心網點配置圖

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

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

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

4 　結論和建議

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

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

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

參　考　文　獻

篇8

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

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

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

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

融合視頻傳送方式可滿足市場需求

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

CVEx平臺具有以下全新特性：

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

可按需對帶寬資源進行會聚并重新分配；

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

篇9

【關鍵詞】 Android 視頻文件 傳輸 處理

一、視頻自適應算法框架

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

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

二、TFRC算法

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

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

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

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

三、基于Android平臺的視頻自適應傳輸算法

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

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

四、總結

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

參 考 文 獻

篇10

關鍵詞：HDMI；硬件編碼；無線傳輸；H264

中圖分類號：TN926+.24；TP393 文獻標識碼：A 文章編號：2095-1302（2017）01-00-03

0 引 言

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

無線視頻傳輸應用中的視頻源和接收端在不同場景中各有不同。例如教學或會議中的無線投影，其視頻源可來自個人電腦的HDMI輸出或VGA輸出，接收端則一般是投影儀的HDMI端口或VGA端口。由于HDMI標準對高清視頻的支持較好，因此在高質量視頻傳輸中，研究HDMI視頻流的無線傳輸方案具有很好的應用價值。

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

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

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

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

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

2 系統(tǒng)軟件設計

2.1 系統(tǒng)配置

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

2.2 視頻編碼

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

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

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

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

2.3 無線傳輸

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

2.4 視頻解碼

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

3 功能測試

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

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

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

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

4 結 語

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

參考文獻

[1]馬思偉.AVS視頻編碼標準技術回顧及最新進展[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)的設計與實現(xiàn)[J].物聯(lián)網技術，2016，6（2）：25-26.

[4]樊曉平，熊哲源，陳志杰，等.無線多媒體傳感器網絡視頻編碼研究[J].通信學報，2011，32（9）：137-146.

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

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