基于智能電視機(jī)的音視頻通信研究與實(shí)現(xiàn)

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

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

基于智能電視機(jī)的音視頻通信研究與實(shí)現(xiàn)

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

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

摘要:在研究SIP協(xié)議、音視頻編解碼的基礎(chǔ)上，提出了一種基于智能電視機(jī)平臺(tái)的音視頻通信解決方案。基于此方案開發(fā)的軟件可實(shí)現(xiàn)Android系統(tǒng)的智能電視機(jī)和手機(jī)之間進(jìn)行音視頻通信。通過(guò)移植實(shí)現(xiàn)跨平臺(tái)開發(fā)，完成Android系統(tǒng)和IOS系統(tǒng)的智能設(shè)備之間音視頻通信。軟件安裝應(yīng)用在創(chuàng)維智能電視機(jī)上，實(shí)踐證明該方案高效、可行。

關(guān)鍵詞:擁塞控制；網(wǎng)絡(luò)穿透；編解碼；點(diǎn)對(duì)點(diǎn)

谷歌的Android系統(tǒng)正向全新的智能電視領(lǐng)域發(fā)展，智能電視將成為繼計(jì)算機(jī)、手機(jī)之后的又一個(gè)重要的智能終端。網(wǎng)絡(luò)音視頻通信在Internet商業(yè)化之后，以其近乎免費(fèi)的優(yōu)勢(shì)在全世界，特別是發(fā)達(dá)國(guó)家迅速發(fā)展起來(lái)。國(guó)內(nèi)也有很多音視頻通信軟件，但是智能電視目前還處于起步階段，音視頻通信軟件無(wú)法直接在智能電視上應(yīng)用。

目前國(guó)內(nèi)電視機(jī)廠商采用的芯片有Mstar，RTK，MTK，Amlogic，Hisi等，各芯片廠家提供的芯片方案差異非常大，使得軟件開發(fā)難度較高，且開發(fā)效率較低。如何在諸多電視芯片方案上實(shí)現(xiàn)音視頻通信，實(shí)現(xiàn)智能電視和智能手機(jī)、平板等智能終端之間音視頻通話急需研究和突破。在智能電視上實(shí)現(xiàn)音視頻通話，向用戶提供優(yōu)質(zhì)的內(nèi)容與服務(wù)可以吸引用戶，有效地利用網(wǎng)絡(luò)資源，提升產(chǎn)品競(jìng)爭(zhēng)力，促進(jìn)技術(shù)升級(jí)和產(chǎn)業(yè)的發(fā)展。

1通信協(xié)議

通信協(xié)議主要有兩種：SIP協(xié)議和RTP協(xié)議。SIP協(xié)議用來(lái)進(jìn)行信令的交互，RTP協(xié)議用來(lái)傳輸音視頻數(shù)據(jù)流。只要有一臺(tái)Android系統(tǒng)的智能電視機(jī)和一個(gè)普通攝像頭，連上網(wǎng)絡(luò)后，即可安裝、使用基于本文解決方案開發(fā)的音視頻通信軟件。

1.1SIP協(xié)議

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

1.2RTP協(xié)議

RTP稱為Real-timeTransportProtocol(實(shí)時(shí)傳輸協(xié)議)。它是IETF提出的一個(gè)標(biāo)準(zhǔn)，對(duì)應(yīng)的RFC文檔為RFC3550。RTP用來(lái)為端到端的實(shí)時(shí)傳輸提供時(shí)間信息和流同步，但并不保證服務(wù)質(zhì)量。服務(wù)質(zhì)量由RTCP來(lái)提供。

主叫端攝像頭采集到音視頻數(shù)據(jù)后，先經(jīng)過(guò)編碼，然后封裝成RTP數(shù)據(jù)包，經(jīng)網(wǎng)絡(luò)發(fā)送到被叫端。被叫端接收到主叫端發(fā)送來(lái)的RTP數(shù)據(jù)包后，從網(wǎng)卡讀取RTP數(shù)據(jù)包，并進(jìn)行解包，然后進(jìn)行解碼，再將解碼后的數(shù)據(jù)播放出來(lái)，從而完成完整的音視頻通話流程。

2標(biāo)準(zhǔn)化

智能電視機(jī)硬件平臺(tái)繁多，差異比較高。必須在各平臺(tái)上進(jìn)行標(biāo)準(zhǔn)化工作，主要包括：音視頻采集、編解碼、音頻播放和視頻渲染。在軟件構(gòu)架的時(shí)候，將軟件進(jìn)行層次劃分、模塊抽象、高內(nèi)聚低偶合。

首先將協(xié)議棧標(biāo)準(zhǔn)化，然后將音視頻通信功能模塊標(biāo)準(zhǔn)化，并集成到Android系統(tǒng)的智能電視操作系統(tǒng)中，使之成為系統(tǒng)服務(wù)。

2.1音頻數(shù)據(jù)標(biāo)準(zhǔn)化

G.729協(xié)議是基于共軛結(jié)構(gòu)代數(shù)碼激勵(lì)線性預(yù)測(cè)的語(yǔ)音壓縮編碼技術(shù)。G.729系列主要包括：G.729標(biāo)準(zhǔn)協(xié)議，G.729A，G.729B，G.729AB。開發(fā)過(guò)程中選擇G.729A[2]作為音頻編碼標(biāo)準(zhǔn)。首先，攝像頭采集原始PCM音頻數(shù)據(jù)，然后采用G729A作為語(yǔ)音壓縮編碼，采樣率8kHz，采樣位數(shù)16bit。編碼后的音頻數(shù)據(jù)封裝為RTP數(shù)據(jù)包發(fā)送到接收端。接收端接收到音頻數(shù)據(jù)后，先拆包，然后采用G.729A解碼音頻數(shù)據(jù)，最后播放音頻數(shù)據(jù)。

2.2視頻數(shù)據(jù)標(biāo)準(zhǔn)化

H.264[3]是由ITU-T視頻編碼專家組(VCEG)和ISO/IEC動(dòng)態(tài)圖像專家組(MPEG)聯(lián)合組成的聯(lián)合視頻組提出的高度壓縮數(shù)字視頻編解碼器標(biāo)準(zhǔn)。視頻數(shù)據(jù)編解碼流程，如圖1所示。

圖1　視頻數(shù)據(jù)編解碼流程

攝像頭采集到的視頻數(shù)據(jù)格式為YUV420P， 然后將采集到的數(shù)據(jù)發(fā)送給編碼器編碼，編出來(lái)的H.264碼流經(jīng)由RTP封包后發(fā)送到接收到端。接收端接收到RTP視頻數(shù)據(jù)后進(jìn)行解碼，最終以YUV420P格式輸出顯示視頻畫面。

2.3硬件編解碼標(biāo)準(zhǔn)化

軟件工作過(guò)程中通過(guò)單獨(dú)的硬件編解碼庫(kù)調(diào)用Android系統(tǒng)的OpenMax層接口執(zhí)行視頻的編解碼，如圖2所示。

圖2　編解碼調(diào)用流程

首先通過(guò)OMXCodec的Create函數(shù)創(chuàng)建編解碼器，然后創(chuàng)建兩個(gè)線程，其中的一個(gè)線程負(fù)責(zé)將待編解碼數(shù)據(jù)發(fā)送給編解碼器，另外一個(gè)線程負(fù)責(zé)將編解碼器輸出的數(shù)據(jù)發(fā)送給上層接口。

2.4音視頻通信模塊標(biāo)準(zhǔn)化

智能電視功能越來(lái)越多，主要包括：網(wǎng)絡(luò)服務(wù)、多媒體服務(wù)、電視服務(wù)、人機(jī)互動(dòng)服務(wù)等。通過(guò)將音視頻通信標(biāo)準(zhǔn)化、模塊化后，集成到電視機(jī)操作系統(tǒng)中，使之成為系統(tǒng)服務(wù)模塊之一。用戶只要購(gòu)買創(chuàng)維電視即可享受到免費(fèi)的音視頻通信服務(wù)。智能電視功能模塊化、標(biāo)準(zhǔn)化后，軟件架構(gòu)如圖3所示。

圖3　智能電視功能模塊標(biāo)準(zhǔn)化

最底層的硬件層主要提供驅(qū)動(dòng)、數(shù)據(jù)注入等服務(wù)；第二層的SkySDK主要是利用標(biāo)準(zhǔn)化技術(shù)，將系統(tǒng)底層服務(wù)進(jìn)行統(tǒng)一封裝，提供基礎(chǔ)軟件接口；第三層是服務(wù)層，主要是智能電視提供的各類服務(wù)，可靈活擴(kuò)展。將音視頻通信制定成標(biāo)準(zhǔn)化的功能模塊，集成到操作系統(tǒng)中；最上層是應(yīng)用層，主要是各類服務(wù)和應(yīng)用界面的展示、操控。

標(biāo)準(zhǔn)化工作完成后，基于本方案開發(fā)的軟件可快速的在其他操作系統(tǒng)設(shè)備上實(shí)現(xiàn)，比如IOS系統(tǒng)、Windows系統(tǒng)、Linux系統(tǒng)。從而實(shí)現(xiàn)不同智能終端之間音視頻通信。

3音視頻通信實(shí)現(xiàn)

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

開發(fā)所用設(shè)備為Android系統(tǒng)智能電視一臺(tái)、攝像頭一個(gè)。

3.1音視頻通信模塊軟件架構(gòu)

開發(fā)過(guò)程中，協(xié)議棧使用C語(yǔ)言開發(fā)，封裝成動(dòng)態(tài)庫(kù)，然后通過(guò)JNI封裝，供應(yīng)用層調(diào)用、顯示。軟件架構(gòu)如圖4所示。

圖4　音視頻通信模塊

為了保障音視頻通信質(zhì)量，針對(duì)音視頻數(shù)據(jù)還需要進(jìn)行流媒體處理，主要措施包括：丟包處理、抖動(dòng)平滑等。

3.2丟包處理

在Internet上用分組傳送話音質(zhì)量不夠好的一個(gè)重要原因是丟包率比較高。尤其在廣域網(wǎng)中，這個(gè)問(wèn)題相當(dāng)突出。特別是實(shí)時(shí)多媒體業(yè)務(wù)對(duì)于延時(shí)的要求相當(dāng)嚴(yán)格，因此不大可能通過(guò)重傳來(lái)解決丟包的問(wèn)題。正是出于這個(gè)原因，本文選擇前向糾錯(cuò)(ForwardErrorCorrection，F(xiàn)EC)機(jī)制用于丟包處理，同時(shí)也可以用于關(guān)鍵幀的保護(hù)來(lái)解決丟包問(wèn)題。

發(fā)送端從媒體數(shù)據(jù)流中取出若干個(gè)數(shù)據(jù)包，并對(duì)它們整個(gè)施以異或操作，包括RTP頭，然后得到一個(gè)包含F(xiàn)EC信息的RTP包。這個(gè)包可以被接收端用來(lái)恢復(fù)任何一個(gè)用來(lái)產(chǎn)生它的包。發(fā)送端需要告訴接收端哪些媒體包被用來(lái)產(chǎn)生了一個(gè)FEC包，這些信息都包含在荷載信息中。每個(gè)FEC包中包含一個(gè)24bit的mask，如果mask的第i個(gè)比特為1，序號(hào)為N+i的媒體包就參與了這個(gè)FEC包的生成。N稱作基序號(hào)，也在FEC包中傳送。通過(guò)此方案就可實(shí)現(xiàn)FEC糾錯(cuò)方案，恢復(fù)丟失的數(shù)據(jù)包。

3.3抖動(dòng)平滑

該設(shè)計(jì)通過(guò)改良Webrtc中的JitterBuffer算法實(shí)現(xiàn)抖動(dòng)平滑功能。JitterBuffer作為抖動(dòng)緩沖區(qū)，它是一個(gè)共享的數(shù)據(jù)區(qū)域，接收端用于平滑網(wǎng)絡(luò)抖動(dòng)、擁塞造成的數(shù)據(jù)波動(dòng)，降低惡劣的網(wǎng)絡(luò)環(huán)境對(duì)音頻流的影響，使得終端用戶感受到一個(gè)清晰的，沒(méi)有失真聲音。緩沖是以犧牲一定的網(wǎng)絡(luò)時(shí)延為代價(jià)的，時(shí)延越大，對(duì)抖動(dòng)的過(guò)濾越好。

JitterBuffer使用到的模塊有FrameBuffer，用來(lái)維護(hù)數(shù)據(jù)元素列表。SessionInfo用于包的拼接，根據(jù)數(shù)據(jù)包的的序列號(hào)對(duì)順序或非順序增長(zhǎng)的包進(jìn)行排列。如果是重傳包，SessionInfo會(huì)負(fù)責(zé)將數(shù)據(jù)包插入到正確的位置上。

4服務(wù)器部署

項(xiàng)目采用客戶端/服務(wù)器和點(diǎn)對(duì)點(diǎn)(C/S+P2P)相結(jié)合的技術(shù)架構(gòu)。點(diǎn)對(duì)點(diǎn)(P2P)方面，實(shí)現(xiàn)了IETF標(biāo)準(zhǔn)STUN、TURN和ICE用于處理NAT穿越問(wèn)題，可以在未知網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中實(shí)現(xiàn)設(shè)備互連。

當(dāng)主叫或被叫有一方的NAT無(wú)法穿透時(shí)，音視頻數(shù)據(jù)必須通過(guò)服務(wù)器轉(zhuǎn)發(fā)。當(dāng)主叫和被叫用戶所處的NAT均可穿透時(shí)，采用P2P策略，數(shù)據(jù)不經(jīng)服務(wù)器轉(zhuǎn)發(fā)，減輕服務(wù)端壓力。服務(wù)器端主要由媒體轉(zhuǎn)發(fā)服務(wù)器和信令服務(wù)器構(gòu)成。

4.1媒體轉(zhuǎn)發(fā)服務(wù)器

媒體轉(zhuǎn)發(fā)服務(wù)器包括MediaDispatcher和MediaRelay兩個(gè)部分，主要負(fù)責(zé)音視頻數(shù)據(jù)轉(zhuǎn)發(fā)。由于NAT類型復(fù)雜，NAT穿越[4]是需要重點(diǎn)解決的問(wèn)題。當(dāng)用戶所處NAT類型無(wú)法穿透時(shí)，利用媒體服務(wù)器轉(zhuǎn)發(fā)音視頻數(shù)據(jù)，保障正常的通信。當(dāng)主叫或被叫有一方的NAT無(wú)法穿透時(shí)，音視頻數(shù)據(jù)必須通過(guò)服務(wù)器轉(zhuǎn)發(fā)。

MediaDispatcher負(fù)責(zé)為呼叫指派一個(gè)用于媒體轉(zhuǎn)發(fā)的Relay。在簡(jiǎn)單的情況下，MediaDispatcher只需要為呼叫指派一個(gè)Relay，然后客戶端的所有媒體數(shù)據(jù)都通過(guò)該Relay來(lái)進(jìn)行轉(zhuǎn)發(fā)。但在跨運(yùn)營(yíng)商的情況下，為了能夠取得較好的通話質(zhì)量，需要兩個(gè)Relay，保障通話質(zhì)量。

MediaRelay幫助轉(zhuǎn)發(fā)媒體數(shù)據(jù)。在跨運(yùn)營(yíng)商的情況下，MediaRelay能夠保證雙方的通話質(zhì)量不受運(yùn)營(yíng)商的策略影響。目前，創(chuàng)維針對(duì)電信、聯(lián)通、廣電3個(gè)運(yùn)營(yíng)商都部署了雙線的Relay。

4.2SIP信令服務(wù)器

SIP服務(wù)器負(fù)責(zé)所有SIP消息的處理。系統(tǒng)中有多臺(tái)SIP服務(wù)器同時(shí)工作，SIP消息會(huì)根據(jù)負(fù)載情況發(fā)送到一臺(tái)SIP服務(wù)器。這些SIP服務(wù)器通過(guò)緩存設(shè)施得到相同的數(shù)據(jù)，因此所有會(huì)話的狀態(tài)和其他注冊(cè)相關(guān)的信息都會(huì)在各臺(tái)SIP服務(wù)器之間共享。SIP消息不需要根據(jù)歷史信息路由到特定的SIP服務(wù)器處理，提高系統(tǒng)的處理能力和可靠性。

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

5總結(jié)

基于本方案開發(fā)的軟件可穩(wěn)定運(yùn)行在Android系統(tǒng)的智能電視機(jī)上，從而實(shí)現(xiàn)智能電視之間的音視頻通信。軟件還可在其他操作系統(tǒng)的手機(jī)、平板等智能終端上，實(shí)現(xiàn)音視頻通信。音視頻通信服務(wù)應(yīng)用到智能電視行業(yè)，即豐富了產(chǎn)品形態(tài)、提升產(chǎn)品競(jìng)爭(zhēng)力，又促進(jìn)了產(chǎn)業(yè)技術(shù)的進(jìn)步。

參考文獻(xiàn)：

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

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

[3]陳靖，劉京，曹喜信.深入理解視頻編解碼技術(shù)-基于H.264標(biāo)準(zhǔn)及參考模型[M]. 北京：北京航空航天大學(xué)出版社， 2012.

[4]朱光，張?jiān)迫A，盧娟.基于ICE的VOIP穿越NAT方案的研究[J].計(jì)算機(jī)應(yīng)用與軟件，2011，10(10)：232-234.

AudioandvideocommunicationresearchandimplementationofsmartTV

SONGQingxi，WANGKezhao，LIXuesong，ZHENGYuming，LIUQian，F(xiàn)ANGWei，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

中圖分類號(hào):TN949

文獻(xiàn)標(biāo)志碼:B

DOI：10.16280/j.videoe.2016.03.010

作者簡(jiǎn)介：

宋慶席(1983— )，碩士，南京創(chuàng)維信息技術(shù)研究院產(chǎn)品經(jīng)理，主要從事智能電視、智能家居方面的研究和開發(fā)。

責(zé)任編輯：時(shí)雯

收稿日期：2015-09-09

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

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