基于智能電視機的音視頻通信研究與實現

宋慶席，王克釗，李雪松，鄭玉明，劉　乾，方　偉，紀建飛

(南京創維信息技術研究院有限公司，江蘇 南京 210000)

基于智能電視機的音視頻通信研究與實現

宋慶席，王克釗，李雪松，鄭玉明，劉乾，方偉，紀建飛

(南京創維信息技術研究院有限公司，江蘇 南京 210000)

摘要:在研究SIP協議、音視頻編解碼的基礎上，提出了一種基于智能電視機平臺的音視頻通信解決方案?；诖朔桨搁_發的軟件可實現Android系統的智能電視機和手機之間進行音視頻通信。通過移植實現跨平臺開發，完成Android系統和IOS系統的智能設備之間音視頻通信。軟件安裝應用在創維智能電視機上，實踐證明該方案高效、可行。

關鍵詞:擁塞控制；網絡穿透；編解碼；點對點

谷歌的Android系統正向全新的智能電視領域發展，智能電視將成為繼計算機、手機之后的又一個重要的智能終端。網絡音視頻通信在Internet商業化之后，以其近乎免費的優勢在全世界，特別是發達國家迅速發展起來。國內也有很多音視頻通信軟件，但是智能電視目前還處于起步階段，音視頻通信軟件無法直接在智能電視上應用。

目前國內電視機廠商采用的芯片有Mstar，RTK，MTK，Amlogic，Hisi等，各芯片廠家提供的芯片方案差異非常大，使得軟件開發難度較高，且開發效率較低。如何在諸多電視芯片方案上實現音視頻通信，實現智能電視和智能手機、平板等智能終端之間音視頻通話急需研究和突破。在智能電視上實現音視頻通話，向用戶提供優質的內容與服務可以吸引用戶，有效地利用網絡資源，提升產品競爭力，促進技術升級和產業的發展。

1通信協議

通信協議主要有兩種：SIP協議和RTP協議。SIP協議用來進行信令的交互，RTP協議用來傳輸音視頻數據流。只要有一臺Android系統的智能電視機和一個普通攝像頭，連上網絡后，即可安裝、使用基于本文解決方案開發的音視頻通信軟件。

1.1SIP協議

會話發起協議(SessionInitiationProtocol，SIP)[1]協議是IETF制定的多媒體通信協議，它是一個基于文本的應用層控制協議，獨立于底層協議，用于建立、修改和終止IP網上的雙方或多方的多媒體會話。SIP協議支持代理、重定向、登記定位用戶等功能，支持用戶移動，與RTP/RTCP、SDP、RTSP、DNS等協議配合，可支持和應用于語音、視頻、數據等多媒體業務。

1.2RTP協議

RTP稱為Real-timeTransportProtocol(實時傳輸協議)。它是IETF提出的一個標準，對應的RFC文檔為RFC3550。RTP用來為端到端的實時傳輸提供時間信息和流同步，但并不保證服務質量。服務質量由RTCP來提供。

主叫端攝像頭采集到音視頻數據后，先經過編碼，然后封裝成RTP數據包，經網絡發送到被叫端。被叫端接收到主叫端發送來的RTP數據包后，從網卡讀取RTP數據包，并進行解包，然后進行解碼，再將解碼后的數據播放出來，從而完成完整的音視頻通話流程。

2標準化

智能電視機硬件平臺繁多，差異比較高。必須在各平臺上進行標準化工作，主要包括：音視頻采集、編解碼、音頻播放和視頻渲染。在軟件構架的時候，將軟件進行層次劃分、模塊抽象、高內聚低偶合。

首先將協議棧標準化，然后將音視頻通信功能模塊標準化，并集成到Android系統的智能電視操作系統中，使之成為系統服務。

2.1音頻數據標準化

G.729協議是基于共軛結構代數碼激勵線性預測的語音壓縮編碼技術。G.729系列主要包括：G.729標準協議，G.729A，G.729B，G.729AB。開發過程中選擇G.729A[2]作為音頻編碼標準。首先，攝像頭采集原始PCM音頻數據，然后采用G729A作為語音壓縮編碼，采樣率8kHz，采樣位數16bit。編碼后的音頻數據封裝為RTP數據包發送到接收端。接收端接收到音頻數據后，先拆包，然后采用G.729A解碼音頻數據，最后播放音頻數據。

2.2視頻數據標準化

H.264[3]是由ITU-T視頻編碼專家組(VCEG)和ISO/IEC動態圖像專家組(MPEG)聯合組成的聯合視頻組提出的高度壓縮數字視頻編解碼器標準。視頻數據編解碼流程，如圖1所示。

圖1　視頻數據編解碼流程

攝像頭采集到的視頻數據格式為YUV420P， 然后將采集到的數據發送給編碼器編碼，編出來的H.264碼流經由RTP封包后發送到接收到端。接收端接收到RTP視頻數據后進行解碼，最終以YUV420P格式輸出顯示視頻畫面。

2.3硬件編解碼標準化

軟件工作過程中通過單獨的硬件編解碼庫調用Android系統的OpenMax層接口執行視頻的編解碼，如圖2所示。

圖2　編解碼調用流程

首先通過OMXCodec的Create函數創建編解碼器，然后創建兩個線程，其中的一個線程負責將待編解碼數據發送給編解碼器，另外一個線程負責將編解碼器輸出的數據發送給上層接口。

2.4音視頻通信模塊標準化

智能電視功能越來越多，主要包括：網絡服務、多媒體服務、電視服務、人機互動服務等。通過將音視頻通信標準化、模塊化后，集成到電視機操作系統中，使之成為系統服務模塊之一。用戶只要購買創維電視即可享受到免費的音視頻通信服務。智能電視功能模塊化、標準化后，軟件架構如圖3所示。

圖3　智能電視功能模塊標準化

最底層的硬件層主要提供驅動、數據注入等服務；第二層的SkySDK主要是利用標準化技術，將系統底層服務進行統一封裝，提供基礎軟件接口；第三層是服務層，主要是智能電視提供的各類服務，可靈活擴展。將音視頻通信制定成標準化的功能模塊，集成到操作系統中；最上層是應用層，主要是各類服務和應用界面的展示、操控。

標準化工作完成后，基于本方案開發的軟件可快速的在其他操作系統設備上實現，比如IOS系統、Windows系統、Linux系統。從而實現不同智能終端之間音視頻通信。

3音視頻通信實現

音視頻通信模塊主要提供音頻通話、視頻通話、通信錄、通話記錄四大功能。通信錄除了提供常規的添加好友、刪除好友、編輯好友和搜索好友之外，還支持對通信錄中的好友進行分組，每個分組可設置不同的組名，便于通信錄管理。

開發所用設備為Android系統智能電視一臺、攝像頭一個。

3.1音視頻通信模塊軟件架構

開發過程中，協議棧使用C語言開發，封裝成動態庫，然后通過JNI封裝，供應用層調用、顯示。軟件架構如圖4所示。

圖4　音視頻通信模塊

為了保障音視頻通信質量，針對音視頻數據還需要進行流媒體處理，主要措施包括：丟包處理、抖動平滑等。

3.2丟包處理

在Internet上用分組傳送話音質量不夠好的一個重要原因是丟包率比較高。尤其在廣域網中，這個問題相當突出。特別是實時多媒體業務對于延時的要求相當嚴格，因此不大可能通過重傳來解決丟包的問題。正是出于這個原因，本文選擇前向糾錯(ForwardErrorCorrection，FEC)機制用于丟包處理，同時也可以用于關鍵幀的保護來解決丟包問題。

發送端從媒體數據流中取出若干個數據包，并對它們整個施以異或操作，包括RTP頭，然后得到一個包含FEC信息的RTP包。這個包可以被接收端用來恢復任何一個用來產生它的包。發送端需要告訴接收端哪些媒體包被用來產生了一個FEC包，這些信息都包含在荷載信息中。每個FEC包中包含一個24bit的mask，如果mask的第i個比特為1，序號為N+i的媒體包就參與了這個FEC包的生成。N稱作基序號，也在FEC包中傳送。通過此方案就可實現FEC糾錯方案，恢復丟失的數據包。

3.3抖動平滑

該設計通過改良Webrtc中的JitterBuffer算法實現抖動平滑功能。JitterBuffer作為抖動緩沖區，它是一個共享的數據區域，接收端用于平滑網絡抖動、擁塞造成的數據波動，降低惡劣的網絡環境對音頻流的影響，使得終端用戶感受到一個清晰的，沒有失真聲音。緩沖是以犧牲一定的網絡時延為代價的，時延越大，對抖動的過濾越好。

JitterBuffer使用到的模塊有FrameBuffer，用來維護數據元素列表。SessionInfo用于包的拼接，根據數據包的的序列號對順序或非順序增長的包進行排列。如果是重傳包，SessionInfo會負責將數據包插入到正確的位置上。

4服務器部署

項目采用客戶端/服務器和點對點(C/S+P2P)相結合的技術架構。點對點(P2P)方面，實現了IETF標準STUN、TURN和ICE用于處理NAT穿越問題，可以在未知網絡拓撲結構中實現設備互連。

當主叫或被叫有一方的NAT無法穿透時，音視頻數據必須通過服務器轉發。當主叫和被叫用戶所處的NAT均可穿透時，采用P2P策略，數據不經服務器轉發，減輕服務端壓力。服務器端主要由媒體轉發服務器和信令服務器構成。

4.1媒體轉發服務器

媒體轉發服務器包括MediaDispatcher和MediaRelay兩個部分，主要負責音視頻數據轉發。由于NAT類型復雜，NAT穿越[4]是需要重點解決的問題。當用戶所處NAT類型無法穿透時，利用媒體服務器轉發音視頻數據，保障正常的通信。當主叫或被叫有一方的NAT無法穿透時，音視頻數據必須通過服務器轉發。

MediaDispatcher負責為呼叫指派一個用于媒體轉發的Relay。在簡單的情況下，MediaDispatcher只需要為呼叫指派一個Relay，然后客戶端的所有媒體數據都通過該Relay來進行轉發。但在跨運營商的情況下，為了能夠取得較好的通話質量，需要兩個Relay，保障通話質量。

MediaRelay幫助轉發媒體數據。在跨運營商的情況下，MediaRelay能夠保證雙方的通話質量不受運營商的策略影響。目前，創維針對電信、聯通、廣電3個運營商都部署了雙線的Relay。

4.2SIP信令服務器

SIP服務器負責所有SIP消息的處理。系統中有多臺SIP服務器同時工作，SIP消息會根據負載情況發送到一臺SIP服務器。這些SIP服務器通過緩存設施得到相同的數據，因此所有會話的狀態和其他注冊相關的信息都會在各臺SIP服務器之間共享。SIP消息不需要根據歷史信息路由到特定的SIP服務器處理，提高系統的處理能力和可靠性。

基于本方案開發的客戶端軟件安裝用MSTAR、RTK、HiSi平臺的智能電視機進行實際測試。視頻通話支持320×240、640×480、1 280×720三種分辨率，依據網絡帶寬及設備處理能力進行分辨率切換。網絡帶寬要求高于4Mbit/s。智能電視機之間、智能手機與智能電視之間音視頻通信延遲在1s以內，音視頻通信流暢、清晰。目前基于本文的解決方案開發的電視機軟件已經在創維智能電視機上實現量產，手機、平板端軟件可到應用市場下載。

5總結

基于本方案開發的軟件可穩定運行在Android系統的智能電視機上，從而實現智能電視之間的音視頻通信。軟件還可在其他操作系統的手機、平板等智能終端上，實現音視頻通信。音視頻通信服務應用到智能電視行業，即豐富了產品形態、提升產品競爭力，又促進了產業技術的進步。

參考文獻：

[1]SPARKSR，DONOVANS，CAMPBELLB.SIP[M]. [S.l.]：Oreilly&AssociatesInc.，2001.

[2]謝代華.利用DM642的G729A音頻壓縮研究與實現[J].電子科技大學學報，2008，37(6)：86-88.

[3]陳靖，劉京，曹喜信.深入理解視頻編解碼技術-基于H.264標準及參考模型[M]. 北京：北京航空航天大學出版社， 2012.

[4]朱光，張云華，盧娟.基于ICE的VOIP穿越NAT方案的研究[J].計算機應用與軟件，2011，10(10)：232-234.

AudioandvideocommunicationresearchandimplementationofsmartTV

SONGQingxi，WANGKezhao，LIXuesong，ZHENGYuming，LIUQian，FANGWei，JIJianfei

(Skyworth Group Nanjing Skyworth IT Institute，Nanjing 210000，China)

Abstract:Based on the research of the SIP protocol，audio codec and video codec， a new solution for audio and video communication based on smart TV platform is proposed in this paper. Based on this scheme software development can be realized between Android smart TV and mobile phone for audio and video communications. Through the transplant to realize cross-platform development， complete the Android and IOS audio&video communication between intelligent terminal equipment. The software installation is applied in the smart TV set of SKYWORTH. The practice proves that the scheme is efficient and feasible.

Key words:congestion control；network address translation；coding/decoding； point to point

中圖分類號:TN949

文獻標志碼:B

DOI：10.16280/j.videoe.2016.03.010

作者簡介：

宋慶席(1983— )，碩士，南京創維信息技術研究院產品經理，主要從事智能電視、智能家居方面的研究和開發。

責任編輯：時雯

收稿日期：2015-09-09

文獻引用格式：宋慶席，王克釗，李雪松，等.基于智能電視機的音視頻通信研究與實現[J].電視技術,2016，40(3)：44-47.

SONGQX，WANGKZ，LIXS，etal.AudioandvideocommunicationresearchandimplementationofsmartTV[J].Videoengineering,2016,40(3)：44-47.