WebRTC下流媒體文件遠程推送與即時播放研究

張寶明++鈕丹倩

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

關鍵詞：流媒體；遠程推送；即時播放；電子商務

DOIDOI：10.11907/rjdk.171649

中圖分類號：TP393

文獻標識碼：A文章編號：16727800（2017）010018203

0引言

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

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

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

1WebRTC技術現狀

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

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

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

圖1視頻文件遠程推送與播放模型

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

2改進與實現

上述方法的缺陷在于：①在進行appendBuffer操作時，缺少任務排隊系統，這樣在接收速度高于寫入速度時導致寫入失敗；②缺少事件處理協調機制，尤其當系統建構到Node.js環境時，由于Node.js具有事件驅動、非阻塞式I/O模型特征，協調機制的缺失會使接收、寫入和播放操作在時序上產生沖突。為此，筆者在建設電子商務平臺（https：//120.25.222.72）時，對遠程Peer端流程進行了改造，加入了排隊系統和協調機制，成功實現了視頻文件的遠程推送和播放，模型見圖2。

圖2改進的視頻文件遠程推送與播放模型

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

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

在接收數據之前，分別將初始值設置為： isFirstChunkUpdating =false和receiveError =false，然后通過以下流程進行協調：

等待數據通道傳來數據，以觸發onmessage事件。

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

（1）判斷傳來的數據是視頻數據塊或是結束標記。若是視頻數據塊，則轉入（2）；若是結束標記，則轉入（3）；

（2）是視頻數據塊，則：

if（receiveError）{

清空queue隊列，丟棄所有已排隊的數據塊；

}else{

將數據塊轉換成Uint8Array格式；

進入queue隊列，排隊等待；

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

設置isFirstChunkUpdating =true；

try{

appendBuffer（queue中第1個數據塊），完成后自動觸發onUpdate事件；

}catch（e）{

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

設置receiveError=true；

}}}

（3）是結束標記，則：

if（！receiveError）{

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

else mediaSource.endOfStream（）；

}

3）onUpdate事件的處理：

if（queue.length>0）{

appendBuffer（queue中第1個數據塊），完成后自動觸發onUpdate事件；

}else{

isFirstChunkUpdating =true；

if（endflag）{

mediaSource.endOfStream（）；

}；

}

經過改進后圓滿實現了流媒體文件的遠程推送與即時播放功能，效果如圖3所示。

圖3遠程Peer端接收推送與即時播放效果

3結語

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

參考文獻參考文獻：

[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].計算機科學，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.

責任編輯（責任編輯：杜能鋼）