• <strike id="fdgpu"><input id="fdgpu"></input></strike>
    <label id="fdgpu"></label>
    <s id="fdgpu"><code id="fdgpu"></code></s>

  • <label id="fdgpu"></label>
  • <span id="fdgpu"><u id="fdgpu"></u></span>

    <s id="fdgpu"><sub id="fdgpu"></sub></s>
     首頁 > 新聞 > 專家觀點 >

    Nikolai Bezruk:實現(xiàn)WebRTC的幾個想法

    2016-07-06 16:07:51   作者:   來源:infoq.com   評論:0  點擊:


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

    專題

    亚洲精品网站在线观看不卡无广告,国产a不卡片精品免费观看,欧美亚洲一区二区三区在线,国产一区二区三区日韩 当涂县| 永胜县| 沧州市| 巴楚县| 泗洪县| 南郑县| 敖汉旗| 长丰县| 汉中市| 尉犁县| 台中市| 龙江县| 呼和浩特市| 沁阳市| 澄迈县| 衡山县| 井冈山市| 莲花县| 张家界市| 胶州市| 肥西县| 达州市| 句容市| 牟定县| 东海县| 理塘县| 子洲县| 镇宁| 雷州市| 康定县| 临洮县| 化德县| 蒙阴县| 亚东县| 乌兰浩特市| 疏附县| 五峰| 翁牛特旗| 三门县| 苏州市| 扬州市| http://444 http://444 http://444 http://444 http://444 http://444