網絡音視訊技術的深入研究

1.音視訊子產品技術體系結構及功能

實時音視訊通信功能，采用B／S結構，分為資料庫層、服務應用層、Web伺服器層和IE用戶端。如圖1所示，通過浏覽器端通路Web伺服器，調用音視訊應用伺服器的業務邏輯以實作音視訊通信，利用通路資料庫伺服器實作資料存取。子產品的核心(服務應用層)是基于公司的Java Framework(JMF)和Java Message Service(JMS)實作的。使用者可通過該模Message塊直接與業務員進行音視訊交流，業務員也可通過該子產品現場錄制一些指導性的音視訊内容面向使用者播放。還可以線上播放一些錄制好的音視訊資源，進而更加友善、快捷地解決問題。

圖1子產品技術體系結構示意圖

2音視訊子產品資料流程

音視訊子產品的音視訊功能是基于JMF實作的，本子產品充分利用了JMF所提供的功能。如圖2所示，其中編解碼處理器(Processor)用于處理音視訊的編解碼，音視訊通路管理器(Session Manager)用于管理所有的音視訊通路。

圖2子產品資料流程示意圖

音視訊資料傳輸流程如下：

(1)首先用戶端請求音視訊交流。

(2)伺服器端會初始化一個音視訊通路管理器用來控制或者記錄即将進行音視訊交流的使用者，并控制整個音視訊傳輸的通路。

(3)捕捉使用者的音頻或者視訊，利用攝像頭和麥克等硬體裝置即可完成。

(4)把捕捉的音頻或視訊資料(Datasource)傳給一個處理音視訊的處理(Processor)，這個處理器是JMF定義的。通過這個處理器可以對源資料編碼壓縮(Encoding)，并且轉換成網絡傳輸需要的資料格式一RTP格式。

(5)把處理好的資料通過音視訊通路管理器傳送給指定的參與者，該傳輸遵循RTP(Real—time TransProt Protocal)協定。

(6)接收音視訊的參與者可以根據其帶寬的大小選擇音頻或視訊或兩者同時進行播放，将接收的資料變換資料格式、解碼(Decoding)，然後傳給播放器(如JMF中的Player)進行播放，播放音視訊的時候要使用同步機制，以實作音視訊的同步播放。

3.音視訊子產品關鍵技術

3．1實時傳輸協定

RTP是一種提供端對端傳輸服務的實時傳輸協定，用來支援在單目标廣播和多目标廣播網絡服中傳輸實時資料，而實時資料的傳輸則由RTCP協定來監視和控制。如圖3所示，使用RTP協定的應用程式運作在RTP之上，由多媒體應用程式生成的音頻和視訊資料塊被封裝在RTP資訊包中，每個RTP資訊被封裝在UDP消息段中，然後再封裝在IP資料包中。本子產品中，RTP執行程式是應用程式的一部分。在送端，本子產品把執行腫協定的資訊包的應用程式中，然後應用程式把RTP資訊包發到UDP的套接接口(Socket Interface)；在接收息包通過UDP套接接口輸入到應用程式，而後執行R1協定的應用程式從R1P資訊包中抽出媒體資料。

圖3 RTP協定層示意圖

本子產品是将RTP協定程式封裝到JMF中執行的，

要程式代碼為：

／／得到原始音頻資料的資料流tracks

TrackControl track[]。proce8sor．getTrackControls()；

AudioFormat audioFormat；

audioFormat=new AudioFormat(AudioFormat．ULAW—R口，8000，8，1)；

for(int i=0；i<track．1ength；i++)

{

……

／／把這些tracks封裝成RTP類型

track[i]．setFormat(audioFormat)

}

3．2 Java音視訊架構

JMF (Java Media Framework)是SUN公司提供音視訊服務的一組架構，分為兩層，如圖4所示。本子產品的音視訊功能主要是通過JMF的一些核心API實作的。JMF Presentation and Processing API是建立在底層API(JMF Plug—in API)的基礎上對音視訊進行處理和控制的，Plug—in API提供了整合器(Multiplex—ers)、分解器(DeMultiplexers)、編解碼器(Codecs)、化器(Effects)和播放(Renders)等摹本功能。子產品的應用程式就建立在這層API的基礎上，這些API接口封裝了底層API複雜的實作，可以直接被應用程式調用，進行音視訊資訊和音視訊控制資訊的傳輸。

圖4 JMF架構示意圖

本子產品調用JMF的主要代碼如下：

／/捕捉音頻資料

AudioFormat format=new AudioFormat(AudioFormat．ULAW，

8000，8，1)；

Vector devices=CaptureDeviceManager．getDevieeList(format)；

CaptureDevicelnfo di=null；

if(devices．size()>0)

di=(CaptureDevicelnfo)devices．elementAt(0)；

else{

System．exit(一1)；

／／建立音視訊的處理器Processor并初始化

try

Pmcess”P Manager．createProeessor(di．getLocator())

}catch(IOException e)

catch(NoProoessorException

prooessor．configure()；

processor．setContentDesc riptor(newContentDeseriptor(

scriptor．RAW))；

／／得到原始音頻資料的資料流tracks，然後把這些tracks封裝

RTP類型

TrackControl

track[]2 prooessor．getTrackControls()；

boolean

encodillIgOk=false；

AudioFormat

audioFormat；

audioFormat=new

AudioFormat(AudioFormat．ULAW—RTP，

for(int

i=0；i<track．1ength；i++)

{if(!eneodinsOk＆＆track[i]instanceof FormatContr01)

{if((track[i])．setFormat(andioFormat)==null)

{track[i]．setEnabled(false)；

encodingOk=true；

{else{

track[i]．setEnabled(false)；

／／建立會話管理器SessionManager。發送資料

DataSource ds=null；

Ds=processor．getDataOutput()；

}catch(NotRealizedError e)

SessionManager rtpsm=new corn．sun．media．卻．

RTPSessionMgr()；

rtpsm．initSession(…)；

rtpsm．atartSession(…)；

rtpsm．ereateSendStream(ds，0)；

}catch(IOException

e．printStackTrace()；

catch(UnsupportedFormatException

3．3 Java消息服務

JMS(Java Message Service)是其公司和其他夥伴公司提供的一種消息服務，它提供了一種通用的方式可以使處于消息系統裡的應用之間或者軟體元件來進行互動(建立、發送、接收、讀取彼此所需要資訊)。JMS定義了一些通用的接口，最小化了程式設計者需要了解的消息中間件的一些概念，但是對消息中間件卻提供了足夠的支援。本子產品的消息體系采用了JMS技術，很友善地解決了子產品的消息互動問題，例如用戶端可以采用JMS中發送消息的方式，告知伺服器端增加或者減少一個使用者；或者發送消息通知其他使用者進行音視訊交流等。

音視訊子產品中JMS應用元件包括提供端(Provid—er)、使用者端(Client)、消息(Message)等幾部分，如圖5所示，其工作流程為：先由标準類庫(J2EE SDK)建立連接配接工廠(Connection Factory)、存放消息的位置(Destination)，并且把它們綁定到命名空間上。工廠建立連接配接，然後連接配接建立出一個會話。發送端(Client)通過命名空間找到對應的工廠和目标，通過工廠建立連接配接，後連接配接建立會話，會話建立消息發送者(Message Producer)，把消息發送到目标。接收端(Client)通過命名空間找到工廠和目标，通過工廠建立連接配接，然後連接配接建立會話，會話建立消息接收者(Message Receiver)，再從目标取得消息。

圖5 JMS工作流程圖

JMS的消息處理方式有點對點(Point—To—Point)和釋出一擷取(Publish—Subscribe)兩種方式?’。考慮到多使用者性，本子產品采用“釋出一擷取”消息機制，即建立在消息話柄(Topic)上，消息被發送到話柄裡，然後接收端(Client)從隊列中取出消息。但是每一個消息可以被多個接收端(Client)接收，而且發送方和接收方存在時間依賴性。發送消息主要代碼如下：

ConnectionFactory topicConnectionFactory；

Context jndiContext；

TopicSession topicSession；

Topic topic；

topicPublisher；TopicPublisher

TextMessage message；

Try

jndiContext=new InitialContext()；

}catch(NamingException e)

System．exit(1)；

／／建立

建連接配接工廠

topicConnectionFactory=(TopicConnectionFactory)jndiCnntext．100kup(”TopicConnec—

tionFactory”)；

／／建立topic

topic=(Topic)jndiContext．100kup(topicName)；

}catch(NalllingException e)

//建立連接配接

topicConnection=topicConnectionFactory．createTopicConnec-

tion()；

//建立會話

topicSession=topicConnection．crealeTopicSession(false，Ses-

sion．AUTO—ACKNOWLEDGE)；

／／建立發送端

topicPublisher=topicSession．createPublisher(topic)；

／／建立文本消息(注：還可以建立對象消息，位元組消息，流消息，圖消息以儲存不同的資訊)

message=topicSession．createTextMessage()；

for(int i=0；i<NUM—MSGS；i++)

message．setText(”This message”+(i+1))；

topiePublisher．publish(message)；

}catch(JMSException e)

4.技術難點及解決方案

4．1降低網絡帶寬占用

網絡帶寬是網絡軟體設計中首先需要考慮的問題之一，開發人員必須在帶寬消耗和服務品質之間取得一個恰當的平衡點。在本系統中，視訊資料和音頻資料編碼格式的優劣是決定帶寬消耗的關鍵，是以應該在保證一定音視訊清晰度的前提下盡可能地采用占用帶寬較低的音視訊編碼格式。考慮到以上要求，本系統在具體實作時分别采用H．263和G．723作為視訊和音頻編碼格式。H．263是ITU在H．261的基礎上開發成功的用作低位率傳輸的視訊編碼格式，它吸收了MPEG标準的若幹概念和思想，非常适合用作網絡多媒體傳輸，因而已為H．323、H．324等視訊會議标準所采用。G．723則是ITU制定的适用于IP電話的語音編碼格式，因其高品質、低碼率而得到廣泛應用。其屬于雙速率語音編碼，可工作在5．3kbps和6．3kbps兩個方式上，同樣已為H．323、H．324等視訊會議标準所采用。在系統測試時，筆者發現隻要适當凋整H．263的編碼品質，就完全可以做到在保證畫面足夠清晰(分辨率為CIF，即352×288)的同時将單個使用者視訊資料的帶寬占用控制在50kbps左右，即使再加上音頻資料，單個使用者所産生的總資料流量也不到60kbps，很好地解決了帶寬消耗和音視訊清晰度之間的沖突。

4．2使用者媒體流管理

由于通信是在多使用者環境下進行的，且每個使用者都将同時發送音頻流和視訊流，是以如何高效實作使用者管理和使用者媒體流管理成為本系統設計中的一個難點。當有新使用者加入時，由于網絡狀态的不确定性，其音頻流和視訊流最初到達同一遠端使用者的時間可能會相差很大。考慮到任何遠端使用者的音頻流和視訊流都必須同時呈現給本地使用者，在隻接收到兩者之一的情況下，是不能認為該使用者已完全加入到通信過程之中的，而是應該等待另一個媒體流的到來，再把該使用者的音頻流和視訊流一并加以呈現。此外，系統還必須對遠端使用者的退出及時作出反應，例如關閉該使用者的媒體播放視窗等。

鑒于以上這些情況，在RTPSender類的遠端媒體流接收子產品中特别設計了兩個Vector類對象，即WaitingList和RunningList。當一新使用者的某一媒體流(音頻流或視訊流)到達時，本地使用者将接收到一個NewReceiveStreamEvent(MediaEvent的一種)。通過這個事件的引用可以檢索到一個辨別媒體流源端的CNAME和一個封裝了媒體流本身的DataSource。隻要将CNAME和DataSource一并存放到WaitingList中，就可在該遠端使用者的另一個媒體流到達時，以相同的CNAME為索引，從WaitingList中檢索出上一次儲存的DataSouree，然後再将之與這次得到的DataSource一并送出給遠端媒體流播放子產品進行播放。之後，再将兩媒體流的共同CNAME(即該遠端使用者的CNAME)及其播放視窗(一個RTPReceiver執行個體)的引用存入RunningList中，并删除WaitingList中有關該遠端使用者的相關資訊(即CNAME和DataSource)，以此表示該遠端使用者已正式加入到本通信系統之中。同樣。當有遠端使用者退出時，本地使用者也将收到一個事件一ByeEvent(同樣是一種MediaEvent)。通過它同樣可以檢索出一個CNAME，進而從RunningList中檢索出對應的播放視窗引用，然後再進行視窗關閉等一系列後續清理工作。最後，删除RunningList中有關該遠端使用者的相關資訊(即CNAME和播放視窗引用)，以此表示該遠端使用者已正式退出本通信系統。綜合以上流程不難看出，WaitingList和RunningList能夠以較小的系統開銷對使用者狀态進行簡單快捷的管理，而且這個過程中絲毫不需要人工幹預，非常好地解決了使用者媒體流管理的難題。

5.結語

本實時音視訊子產品的設計研發，借鑒了國内外數字系統的經驗，采用了國際先進的音視訊技術，符合國際數字系統的标準，系統子產品運作狀況及測試效果良好。對于該系統子產品的未來走向，如下：

圖6 3GP、MP4視訊轉換精靈”主界面

圖7 音視訊面對面界面

(1)利用網格技術來解決帶寬的問題，以保證音視訊的品質和跨地域性，可以在每一個地域上布置一個網格伺服器。

(2)利用現在的Web服務技術跨平台的特性，可以使目前已經存在的各種音視訊咨詢系統互通，進而形成一個整體的全球化的合作系統，并且可以通過各種終端進行連接配接，随時随地利用各種通信工具進行咨詢。

(3)從系統的性能上考慮，應加強系統的協同性和即時性，也就是要追求系統的響應速度。

(4)随着網絡技術的不斷發展，安全問題日益重要，增強系統的穩定性、安全性等應用性能。

本文轉自 fanxiaojun 51CTO部落格，原文連結：http://blog.51cto.com/2343338/432220，如需轉載請自行聯系原作者

網絡音視訊技術的深入研究

繼續閱讀

關于Gradle配置的小結

Java小案例——随機數猜測随機數猜測

nginx location中斜線的位置的重要性

27 Best Free Eclipse Plug-ins for Java Developer to be ProductiveCode Quality PluginsText Editor PluginsDependency ManagementVersion Control Integration PluginsFramework Development Continuous Integration Related PluginsOther Utility Plugins

Java String.format方法的簡單使用

neo4j之cypher使用文檔

GitHub連夜封殺！這份阿裡 10W 字内部 Java 字面試手冊到底有多強？

spark/scala關于【資源檔案】加載方法概述外部檔案加載方案測試資源檔案打包入jar包中小結

mybatis_入門程式Mybatis入門

AOP程式設計_Android優雅權限架構(1)概念基礎，2021金三銀四前言正文大綱正文

Effective Java 8:通用程式設計

OOM三種類型

工廠模式-三種類型

【遞歸】高效率求2的n次幂

win10本地scala和spark安裝安裝scala安裝spark

scala (3) Function 和 Method