不借助第三方應(yīng)用，快速且安全地在瀏覽器中傳輸視頻——這有可能實(shí)現(xiàn)嗎？根據(jù)你的需求，有不止一種方式能夠?qū)ebRTC添加到你的站點(diǎn)之中。
WebRTC（Web實(shí)時(shí)通信，Web Real-Time Communication）是一項(xiàng)開源技術(shù)，用來在Web瀏覽器中實(shí)現(xiàn)實(shí)時(shí)直接的多媒體通信功能。它能夠在兩個(gè)或更多的人之間建立端到端的連接，這對于傳輸媒體（音頻和視頻流）來說是非常合適的。這項(xiàng)技術(shù)已經(jīng)在如下的瀏覽器中得到了支持：Google Chrome、Mozilla Firefox和Opera。對于這些瀏覽器，我們不需要額外的插件。只需要打開一個(gè)Web瀏覽器頁面并開啟一個(gè)會(huì)話就可以了。對于使用Safari和IE的用戶來說，沒有原生的支持，但是我們可以添加特定的插件。
理念是非常簡單的。首先，瀏覽器發(fā)送一個(gè)信號(hào)到WebRTC服務(wù)器，這個(gè)服務(wù)器是用戶希望初始化調(diào)用的。在獲取到服務(wù)器的連接之后，用戶將其發(fā)送給他的同伴。瀏覽器彈出的窗口會(huì)提示用戶訪問Web攝像頭和麥克風(fēng)的權(quán)限。如果用戶使用HTTPS協(xié)議的話，瀏覽器能夠記住你所選擇的選項(xiàng)（是否授予權(quán)限）。如果你使用HTTP協(xié)議的話，在每次嘗試連接的時(shí)候，瀏覽器都會(huì)向你申請權(quán)限。
如果你是用戶的話，這聽起來非常簡單。但是，作為開發(fā)人員，又該如何呢？在Web站點(diǎn)上如何實(shí)現(xiàn)它呢？如果你所需要的不僅僅是視頻聊天，還要使用Web攝像頭進(jìn)行記錄，并將錄制的結(jié)果發(fā)送到Amazon S3存儲(chǔ)中，這樣第三方就有可能瀏覽這個(gè)錄制結(jié)果，那又該怎樣實(shí)現(xiàn)呢？對于一些場景來說，這種方式是非常棒的，比如收集某些商品和服務(wù)的視頻回訪，當(dāng)某位討論成員不在場的時(shí)候，為其記錄視頻信息，為工作的求職者進(jìn)行面試，Web支持等等。
我們都知道，視頻格式有很多種。它們中的大多數(shù)在某些方面都具有一定的優(yōu)勢。例如，我可以選擇Flash格式（FLV、F4V）來記錄視頻，但是這項(xiàng)技術(shù)在Web中正在逐漸失勢。多個(gè)瀏覽器都已經(jīng)宣布將來不再支持Flash，這也是我選擇使用WebRTC的另外一個(gè)原因。Flash使用H。264視頻編碼解碼器，而WebRTC使用VP8.WebRTC標(biāo)準(zhǔn)中規(guī)定要支持H。264，但是它還沒有得到廣泛地應(yīng)用。VP8是免費(fèi)的（H。264并非如此），視頻文件的質(zhì)量和大小幾乎是相同的。
我開始選擇使用的是免費(fèi)的Java Script庫，名為Media Stream Recorder，它用于跨瀏覽器的音頻/視頻記錄。這個(gè)庫通常會(huì)與WebRTC實(shí)現(xiàn)相關(guān)。不過令人遺憾的是，在這個(gè)過程中，我遇到了很多技術(shù)難題。例如，每次記錄完成時(shí)，瀏覽器會(huì)停止響應(yīng)，并且會(huì)很多的延遲（lag）。
然后，我嘗試使用WebRTC Experiments庫。它使用了相同的技術(shù)，但是實(shí)現(xiàn)不同。記錄完成時(shí)，它的延遲時(shí)間和瀏覽器行為都是正常的。
使用這個(gè)庫的結(jié)論如下所示：
優(yōu)點(diǎn)：
- 不需要運(yùn)行服務(wù)器，所有的負(fù)載都會(huì)落到瀏覽器端。
- 錄制過程的控制非常容易：只需點(diǎn)擊pause鍵，就能開始新的錄制和停止錄制。
- 沒有延遲，因?yàn)樗械氖虑槎际窃贙urento中完成的（我稍后將會(huì)對其進(jìn)行介紹）。
不足：
- Google Chrome會(huì)分別記錄視頻和音頻，這樣最終會(huì)有兩個(gè)不同的文件：音頻文件以及沒有音頻的視頻文件。
- 如果錄制時(shí)間超過五分鐘的話，瀏覽器會(huì)停止響應(yīng)，用戶的命令會(huì)被忽略掉。
- 在錄制停止時(shí)，將會(huì)耗費(fèi)幾秒鐘的時(shí)間來解碼視頻和接收數(shù)據(jù)。
- 它將會(huì)耗費(fèi)一些時(shí)間將視頻發(fā)送到倉庫中。如果在文件傳輸?shù)倪^程中，用戶關(guān)閉了瀏覽器的tab標(biāo)簽，數(shù)據(jù)將會(huì)出現(xiàn)丟失。
我需要一個(gè)服務(wù)器來接收來自客戶端的視頻流并對其進(jìn)行記錄。對我來講，一個(gè)較為合適的方案是使用Kurento Media Server，我在Amazon EC2上使用STUN/TURN服務(wù)器進(jìn)行了搭建。我使用Kurento庫實(shí)現(xiàn)了前端（不需要使用中間服務(wù)器）。Kurento（英語中“stream”這個(gè)詞的世界語名稱）是一個(gè)開源的框架，它提供了一個(gè)媒體服務(wù)器，這個(gè)服務(wù)器基于標(biāo)準(zhǔn)提供了任意媒體的處理功能。
最終，對于我來講，無法接受這樣的結(jié)果，但是如果上述的不足對你來講不那么重要的話，那你可以使用這種方法。因?yàn)槲业南敕ㄊ潜M可能實(shí)現(xiàn)最優(yōu)的結(jié)果，因此我又開始尋找其他的解決方案。
有時(shí)候，我們所需要的記錄文件并不僅僅只有一個(gè)。如果我們基于某些原因，需要將流劃分為多個(gè)部分，例如應(yīng)用只能接收三分鐘或五分鐘的視頻記錄（以避免出現(xiàn)過載的情況），那該怎么做呢？我思考過如何將一個(gè)小時(shí)的記錄劃分為12個(gè)五分鐘的記錄，每一個(gè)都保存為一個(gè)單獨(dú)的文件。我嘗試的做法是每次都停止錄制，斷開與服務(wù)器的連接并重新開始錄制（再次連接到服務(wù)器）。使用Kurento無法正常運(yùn)行，這是因?yàn)槲颐看沃匦逻B接服務(wù)器的時(shí)候，會(huì)丟掉幾秒鐘的記錄（連接不是瞬時(shí)完成的）。
于是，我決定采用一個(gè)連接，使用Web攝像頭進(jìn)行無停止的錄制。稍后，我要將記錄進(jìn)行分割并將其發(fā)送到Amazon S3上，這個(gè)過程中，我決定使用node-fluent-ffmpeg庫。為了完成該功能，我搭建了一個(gè)新的服務(wù)器，但是這里還有一個(gè)難題。Kurento會(huì)將文件保存為webm格式，在Google Chrome上無法正確地播放（Mozilla Firefox不會(huì)有這個(gè)問題）：視頻流播放地比音頻流更快。修正這個(gè)問題的最佳方式是講文件重編碼為mp4，這樣就能解決這個(gè)問題了。
最終，所有的事情都能正常運(yùn)行了。我使用WebRTC技術(shù)構(gòu)建了完整的流程，在當(dāng)前的任務(wù)下解決了所有的問題。當(dāng)然，實(shí)現(xiàn)并不是100%完美的，我們同時(shí)可以看到它的優(yōu)勢和不足：
優(yōu)點(diǎn)：
- 視頻和音頻位于同一個(gè)文件中，沒有將其分為兩個(gè)單獨(dú)的文件。
- 視頻是以實(shí)時(shí)的模式錄制的，不會(huì)丟失視頻文件。如果在客戶端一側(cè)實(shí)現(xiàn)錄制的話，用戶在退出我們的服務(wù)之前，必須要等待文件上傳到倉庫之中。
不足：
- 連接到Kurento Media Server需要耗費(fèi)一些時(shí)間。
- 網(wǎng)絡(luò)傳輸。客戶端的帶寬要足夠快。
- 實(shí)現(xiàn)起來比較困難，這不僅涉及到資源還涉及到時(shí)間。我必須要搭建Kurento Media Server、coturn以及Node.js，其中Node.js會(huì)用來將視頻轉(zhuǎn)換為另外一種格式，將其拆分為多個(gè)部分，并將其發(fā)送到S3中。
WebRTC技術(shù)是很新的，所以在安全性上會(huì)有一些問題。它所使用的加密構(gòu)建在TLS協(xié)議之上。我們會(huì)發(fā)現(xiàn)安全漏洞，但是這可能并不是WebRTC技術(shù)的問題，而是信號(hào)傳輸所使用的瀏覽器本身的問題。WebRTC的主要問題在于它很容易和快速地暴露真實(shí)的用戶IP地址，它并沒有使用代理、VPN、Tor或流行的插件如Ghostery進(jìn)行保護(hù)。為了使用WebRTC組織視頻或音頻會(huì)話，兩臺(tái)電腦必須發(fā)送IP地址給對方（不僅包括公網(wǎng)IP，還包括私有IP）。我們可以在Java Script中使用簡單的腳本來請求地址，在個(gè)人數(shù)據(jù)保護(hù)方面，這是一個(gè)巨大的問題，這個(gè)問題只能通過禁用WebRTC來解決。
這里有很大的提升空間，首先就是瀏覽器的良好支持。
你也可以看到，這里并沒有完美的答案。這項(xiàng)技術(shù)有好處也有壞處，有優(yōu)勢也有不足，但是WebRTC正在迅速地流行起來。使用WebRTC的統(tǒng)計(jì)數(shù)據(jù)是令人興奮的。有47%的商業(yè)組織計(jì)劃在未來的12個(gè)月中使用該技術(shù)，或者已經(jīng)使用了該技術(shù)。90%的受訪者相信WebRTC有潛力提升客服中心的服務(wù)水平。超過720家公司正在以某種實(shí)行使用WebRTC。
我們可以預(yù)期WebRTC將會(huì)影響通信市場，有多種方式來使用該項(xiàng)技術(shù)。例如，假設(shè)在線商店會(huì)有一個(gè)“客戶支持”的鏈接，我們可以點(diǎn)擊這個(gè)鏈接并與客服進(jìn)行視頻聊天、詢問問題并得到建議。這都是在瀏覽器中實(shí)現(xiàn)的，不需要額外的應(yīng)用或插件。這能夠在很大程度上提升客戶服務(wù)的質(zhì)量，因而有利于增加利潤。這意味著致力于成為市場領(lǐng)導(dǎo)者的公司會(huì)迅速使用這項(xiàng)技術(shù)，其余的公司將會(huì)隨之跟進(jìn)。
現(xiàn)實(shí)中使用傳統(tǒng)電話呼叫的很多領(lǐng)域正在被快速的鏈接點(diǎn)擊或Web通信器的消息所取代。相對于打電話，通過在站點(diǎn)上點(diǎn)擊鏈接，會(huì)更加容易地打出租車、訂餐等等。這是可以使用WebRTC技術(shù)的一個(gè)領(lǐng)域。它起初與通用的視頻聊天（如Skype）和電話呼叫進(jìn)行競爭。誰知道呢，也許在未來的幾年內(nèi)，WebRTC將會(huì)改變我們的日常習(xí)慣。
關(guān)于作者
Nikolai Bezruk是Qualium Systems的Java Script開發(fā)人員，這家公司致力于為創(chuàng)業(yè)公司和數(shù)字代理公司創(chuàng)建Web和移動(dòng)應(yīng)用。Nikolai擔(dān)任團(tuán)隊(duì)領(lǐng)導(dǎo)和軟件架構(gòu)師，進(jìn)行全棧的Web編程。他同時(shí)還負(fù)責(zé)培訓(xùn)新員工。
