張寶明++鈕丹倩

摘要：WebRTC是推動互聯(lián)網(wǎng)經(jīng)濟(jì)向前發(fā)展的重要技術(shù)，但存在應(yīng)用模式不成熟，應(yīng)用范圍有限，與電子商務(wù)缺乏深度融合等問題。探討了WebRTC的應(yīng)用模式及其實現(xiàn)技術(shù)。分析了現(xiàn)行流媒體文件遠(yuǎn)程推送與即時播放方法的不足；通過增加排隊系統(tǒng)和協(xié)調(diào)機(jī)制，設(shè)計了基于事件響應(yīng)的處理模型，豐富了電子商務(wù)視頻應(yīng)用解決方案。

關(guān)鍵詞：流媒體；遠(yuǎn)程推送；即時播放；電子商務(wù)

DOIDOI：10.11907/rjdk.171649

中圖分類號：TP393

文獻(xiàn)標(biāo)識碼：A文章編號：16727800（2017）010018203

0引言

WebRTC（Web RealTime Communication，網(wǎng)頁實時通信）是第4代Web應(yīng)用技術(shù)[1]，自2012年出現(xiàn)以來一直受到追捧。其核心要義在于集成音視和視頻，繞過服務(wù)器，通過信令直接在瀏覽器和瀏覽器之間（peertopeer）建立信道，實現(xiàn)瀏覽器與瀏覽器之間的實時通信，以拓展Web應(yīng)用，推動互聯(lián)網(wǎng)經(jīng)濟(jì)向前發(fā)展[23]。

隨著WebRTC技術(shù)不斷成熟、功能逐漸完善，建立在其技術(shù)基礎(chǔ)之上的視頻會議、可視通信等應(yīng)用也得以推廣，在電子商務(wù)、網(wǎng)絡(luò)社區(qū)中屢屢可見其身影。然而，受到技術(shù)條件的限制和監(jiān)管政策的約束，與Web應(yīng)用第2代技術(shù)Ajax和第3代技術(shù)WebSocket出現(xiàn)后，集中爆發(fā)的新模式如微博、維基、社交網(wǎng)絡(luò)等應(yīng)用相比，基于WebRTC技術(shù)的應(yīng)用目前還僅局限于視頻會議和可視通信，與電子商務(wù)和電子政務(wù)的深度融合尚未開始，應(yīng)用范圍較為有限，應(yīng)用模式還不夠清晰，缺少必要的創(chuàng)新。因此，探討WebRTC技術(shù)下新的應(yīng)用模式顯得尤為重要。

本文探討了WebRTC技術(shù)新的應(yīng)用模式：流媒體文件的遠(yuǎn)程推送與即時播放，目的是在實時通信過程中，利用WebRTC技術(shù)向其它遠(yuǎn)程端瀏覽器（遠(yuǎn)程Peer）推送流媒體文件，并及時播放（一邊推送一邊播放，而不是等推送完再播放）。這樣不但能減少遠(yuǎn)程客戶端等待時間，改善用戶體驗，還能由此產(chǎn)生新的商業(yè)模式，實現(xiàn)諸如電子商務(wù)中的廣告插播、音樂商店中的體驗播放、教育網(wǎng)站上的明師名家視頻教學(xué)等應(yīng)用。

1WebRTC技術(shù)現(xiàn)狀

對于WebRTC技術(shù)相關(guān)文獻(xiàn)有一些探討。如在W3C組織推薦的《W3C Working Draft for Audio API 1.0》[4]草案中，就提出了MediaStream概念，將本地播放的視頻、音頻流（即網(wǎng)頁中用于播放視頻和音頻文件的

作為階段性成果，目前在一些瀏覽器（如chrome、FireFox）中，已經(jīng)可以通過AudioContext對象，運(yùn)用createBufferSource（）方法，將本地

通常，WebRTC有3個重要的腳本接口：①M(fèi)ediaStream，用于通過攝像頭及話筒獲得視頻、音頻的同步流；②RTCPeerConnection，用于構(gòu)建PeerPeer流媒體通道；③RTCDataChannel，用于構(gòu)建數(shù)據(jù)通道。文獻(xiàn)[6]提出利用RTCDataChannel接口實現(xiàn)視頻文件的遠(yuǎn)程推送和播放，具體方法如下：①在本地Peer打開視頻文件（WebM或MP4格式）；②通過FileReader將其數(shù)據(jù)以Uint8Array格式讀到緩沖區(qū)buffer中；③將緩沖區(qū)buffer中的數(shù)據(jù)分割成若干個數(shù)據(jù)塊（每個數(shù)據(jù)塊不大于3 000字節(jié)），并通過RTCDataChannel信道傳送給遠(yuǎn)程Peer端；④遠(yuǎn)程Peer端收到數(shù)據(jù)塊后，立即寫入（不等收到所有數(shù)據(jù)塊）一個屬于MediaSource的SourceBuffer對象中（即所謂的appendBuffer操作），并通過預(yù)先與

圖1視頻文件遠(yuǎn)程推送與播放模型

SourceBuffer關(guān)聯(lián)多個對象，其寫入操作較為復(fù)雜，需要進(jìn)行一系列指令處理，存在一定的時間延遲，這在視頻文件較小、發(fā)送速度較慢的情況下沒有多大問題。但是，在數(shù)據(jù)發(fā)送量加大、接收速度加快的情況下，由于時間延遲的存在，致使前一個appendBuffer操作尚未完成，就需要立即響應(yīng)后一個appendBuffer操作，導(dǎo)致通信失敗。

2改進(jìn)與實現(xiàn)

上述方法的缺陷在于：①在進(jìn)行appendBuffer操作時，缺少任務(wù)排隊系統(tǒng)，這樣在接收速度高于寫入速度時導(dǎo)致寫入失?。虎谌鄙偈录幚韰f(xié)調(diào)機(jī)制，尤其當(dāng)系統(tǒng)建構(gòu)到Node.js環(huán)境時，由于Node.js具有事件驅(qū)動、非阻塞式I/O模型特征，協(xié)調(diào)機(jī)制的缺失會使接收、寫入和播放操作在時序上產(chǎn)生沖突。為此，筆者在建設(shè)電子商務(wù)平臺（https：//120.25.222.72）時，對遠(yuǎn)程Peer端流程進(jìn)行了改造，加入了排隊系統(tǒng)和協(xié)調(diào)機(jī)制，成功實現(xiàn)了視頻文件的遠(yuǎn)程推送和播放，模型見圖2。

圖2改進(jìn)的視頻文件遠(yuǎn)程推送與播放模型

首先，在接收數(shù)據(jù)和申請寫入數(shù)據(jù)模塊中增加一個排隊系統(tǒng)queue，在數(shù)據(jù)抵達(dá)事件發(fā)生后，先將數(shù)據(jù)放入queue隊列排隊，然后依據(jù)queue中是否存在唯一的數(shù)據(jù)塊，決定是否發(fā)起 appendBuffer操作，實現(xiàn)將數(shù)據(jù)塊寫入SourceBuffer并及時播放。這樣，就改變了以前只要收到數(shù)據(jù)就立即插入sourceBuffer而帶來的速度不匹配問題。

其次，在onMessage、onUpdate和onLoad事件處理模塊間加入了時序協(xié)調(diào)機(jī)制。為此，增加兩個全局變量：isFirstChunkUpdating、receiveError，分別表示“queue中第1個數(shù)據(jù)塊正在進(jìn)行appendBuffer操作”、“appendBuffer操作過程中發(fā)生了錯誤”。

在接收數(shù)據(jù)之前，分別將初始值設(shè)置為： isFirstChunkUpdating =false和receiveError =false，然后通過以下流程進(jìn)行協(xié)調(diào)：

等待數(shù)據(jù)通道傳來數(shù)據(jù)，以觸發(fā)onmessage事件。

onmessage事件的處理。過程代碼如下：

（1）判斷傳來的數(shù)據(jù)是視頻數(shù)據(jù)塊或是結(jié)束標(biāo)記。若是視頻數(shù)據(jù)塊，則轉(zhuǎn)入（2）；若是結(jié)束標(biāo)記，則轉(zhuǎn)入（3）；

（2）是視頻數(shù)據(jù)塊，則：

if（receiveError）{

清空queue隊列，丟棄所有已排隊的數(shù)據(jù)塊；

}else{

將數(shù)據(jù)塊轉(zhuǎn)換成Uint8Array格式；

進(jìn)入queue隊列，排隊等待；

if（！isFirstChunkUpdating &&queue.length==1）{

設(shè)置isFirstChunkUpdating =true；

try{

appendBuffer（queue中第1個數(shù)據(jù)塊），完成后自動觸發(fā)onUpdate事件；

}catch（e）{

//若捕捉到錯誤，則說明傳送的不是視頻文件

設(shè)置receiveError=true；

}}}

（3）是結(jié)束標(biāo)記，則：

if（！receiveError）{

if（queue.length>0 || appendBuffer操作正在進(jìn)行中） endflag=true；

else mediaSource.endOfStream（）；

}

3）onUpdate事件的處理：

if（queue.length>0）{

appendBuffer（queue中第1個數(shù)據(jù)塊），完成后自動觸發(fā)onUpdate事件；

}else{

isFirstChunkUpdating =true；

if（endflag）{

mediaSource.endOfStream（）；

}；

}

經(jīng)過改進(jìn)后圓滿實現(xiàn)了流媒體文件的遠(yuǎn)程推送與即時播放功能，效果如圖3所示。

圖3遠(yuǎn)程Peer端接收推送與即時播放效果

3結(jié)語

通過WebRTC技術(shù)實現(xiàn)流媒體文件的遠(yuǎn)程推送與即時播放，首先需要在遠(yuǎn)程端生成一個mediaSource對象，并成為播放部件

參考文獻(xiàn)參考文獻(xiàn)：

[1]W3C. HTML5[EB/OL]. [20161213]. http：//www.w3.org/TR/html5/.

[2]SALVATORE LORETO， SIMON PIETRO ROMANO. Realtime communication with WebRTC： peertopeer in the browser[M]. OReilly Media，2014.

[3]張向輝，黃佳慶，吳康恒，等.基于WebRTC的實時視音頻通信研究綜述[J].計算機(jī)科學(xué)，2015，42（2）：16.

[4]CHRIS ROGERS. Audio API 1.0[EB/OL].[20161211]. https：//www.w3.org/2011/audio/drafts/1WD/.

[5]MOZILLA DEVELOPMENT NETWORK. Web technology for developers[EB/OL].[20161225].https：//developer.mozilla.org/enUS/docs/Web/API/AudioContext.

[6]MUAZ KHAN. Prerecorded media streaming[EB/OL].[2016108].https：//www.webrtcexperiment.com/streamer.js.

責(zé)任編輯（責(zé)任編輯：杜能鋼）