本文主要介紹WebRTC （我們翻譯和整理的，譯者：weizhenwei，校驗：blacker），最早發表在【編風網】
支持原創，轉載必須注明出處，歡迎關注我的微信公眾號blacker（微信ID：blackerteam 或 webrtcorgcn）。
回顧：Android IOS WebRTC 音視頻開發總結（八十三）-- 使用WebRTC廣播網絡攝像頭視頻（上）
連接網絡攝像頭
正如上文所提，我們選用一款簡單的D-Link DCS-7010L網絡攝像頭。關鍵原因在於它支持RTSP協議，因此服務器可以從攝像頭中獲取視頻流。
我們使用插接線把攝像頭和路由器連接起來。攝像頭開啟后，通過DHCP協議識別路由器並獲取IP地址，在這里是192.168.1.34。如果你打開路由器設置，你會發現一台已連接設備DCS 7010，這就是我們的攝像頭。現在開始測試這台網絡攝像頭。
在瀏覽器中打開192.168.1.34，進入攝像頭的Web管理界面，密碼默認為空。
如你所見，在管理面板上攝像頭的視頻流播放地很流暢。盡管如此，我們還是能夠看到抖動現象。這正是我們要用WebRTC修正的問題。
配置網絡攝像頭
首先，我們禁用認證功能。基於測試目的，我們允許任何人觀看廣播。具體設置是，進入Setup－Network頁面，設置Authentication為Disable。
在同一設置界面，我們檢查RTSP協議的端口是否正確，默認是554。輸出視頻格式在檔次中確定。你可以設置為3檔次，但是我們使用第一個live1.sdp，它已經分別為音視頻配置H.264和G.711。這里所做的任何設置都可以通過Setup－Audio and Video修改。
現在我們可以通過RTSP測試攝像頭。打開VLC播放器(或其它任何支持RTSP協議的播放器，例如QuickTime，Window Media Player，RealPlayer，等等)，打開URL對話框設置攝像頭的RTSP地址：rtsp://192.168.1.34/live1.sdp。
OK，它如預期那樣工作。攝像頭通過RTSP發送視頻流到播放器。
此外，視頻流播放非常流暢，沒有任何瑕疵。我們期待WebRTC能有同樣表現。
安裝服務器
至此，攝像頭已經安裝完畢，並且用桌面播放器進行過測試。我們已經准備好使用服務器進行廣播。借助於whatismyip.com網站可以確定攝像頭的外網IP地址是178.51.142.223。現在需要配置路由器，把所有經過554端口發送的RTSP請求重定向到網絡攝像頭。
打開路由器的對應設置頁面：
並使用telnet檢查外網IP地址和RTSP端口：
telnet 178.51.142.223 554
確定端口能夠響應請求后，我們開始安裝WebRTC服務器。
托管服務我們使用Amazon EC2 CentOS 64位服務器。為減少性能問題，我們選擇配置一個VCPU的m3.medium實例：
當然，可供選擇的還有Linode和DigitalOcean，但這次我們決定使用Amazon。為使示例工作起來，我們需要在AmazonEC2控制面板上配置端口，WebRTC和RTSP/RTP都需要這些端口。如果你也想測試示例，那么要確保Amazon接收流量面板配置如下：
DigitalOcean的配置更加簡單，你僅需要在防火牆關閉這些端口，或者完全禁用。根據我們使用DigitalOcean的經驗，它們提供靜態IP，不會和NAT混淆在一起。因此，DigitalOcean並不需要像Amazon那樣配置端口。
作為向WebRTC廣播RTSP/RTP的服務端軟件，我們使用WebRTC媒體廣播服務器軟件Flashphoner。該流媒體服務器很像可以通過Flash廣播RTSP/RTP 的Wowza。唯一不同的是Flashphoner通過WebRTC傳輸流媒體，而不是Flash。從技術上說，這意味着瀏覽器和服務器之間通過DTLS通信，建立SRTP會話，傳送VP8編碼的視頻流到觀眾面前。
接下來安裝服務器需要的SSH。
完整的服務器軟件安裝清單如下：
2.提取軟件
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3.安裝軟件
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
配置服務器的外網IP地址：54.186.112.111，內網IP地址：172.31.20.65。
4.開啟服務
$service webcallserver start
5.檢查日志
$tail — f/usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6.確認服務正在運行
$ps aux | grep Flashphoner
7.裝並開啟apache服務
$yum install httpd
$service httpd start
8.下載web文件並放置到apache默認目錄/var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9.在配置文件flashphoner.xml中配置服務器的IP地址。
10.關閉防火牆
$service iptables stop
理論上說，你應該在第10步配置防火牆端口和規則，而不是關閉它。但基於測試目的，我們直接把防火牆關掉。
配置服務器
我們的WebRTC廣播服務架構如下：
我們已經配置好圖中的節點，現在我們需要配置節點之間的箭頭連接。
Web客戶端負責瀏覽器和WebRTC之間互聯，可以從github下載源碼。JS，CSS和HTML文件在安裝期間上傳到／var/www/html目錄(看上節第九步)。
瀏覽器－服務器通信在flashphoner.xml中配置，我們在該文件中寫入服務器的外網IP地址，因此Web客戶端可以通過HTML5 websocket連接WebRTC服務器。
OK，我們已經配置好服務器，現在讓我們測試一下：
在瀏覽器中打開Web客戶端索引頁面index.html：
http://54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdpwebrtc-ipcam.ddns.net是一個從noip.com動態域名服務器獲得的免費域名，它能夠連接到我們的外網IP地址。並且，我們已經配置路由器，根據NAT規則把發送到192.168.1.34的RTSP請求進行重定向。
參數id=rtsp://webrtc-ipcam.ddns.net/live1.sdp設置視頻流的URL。WebRTC服務器從網絡攝像頭獲取視頻流，處理后用WebRTC廣播到瀏覽器。你的路由器可能支持DDNS，如果不支持的話，可以使用攝像頭選項：
下面是在路由器中設置DDNS：
最后，我們來測試系統查看結果。
測試
鏈接從瀏覽器打開，連接到WebRTC服務器。服務器發送請求到網絡攝像頭以獲取視頻流。這個過程需要幾秒鍾時間。
瀏覽器通過WebSocket連接到服務器，然后服務器通過RTSP向攝像頭發送請求，得到用RTP封裝的H.264流，進而轉碼為VP8/SRTP格式，最終在WebRTC兼容瀏覽器上進行播放。
經過一小段延遲后，我們可以看到熟悉的畫面：
視頻底部顯示視頻流的URL地址，你可以復制后在另一個瀏覽器中打開。
確認WebRTC在工作
如果我們作弊怎么辦？即來自網絡攝像頭的視頻仍然通過HTTP傳輸。我們不要只相信看到的視頻流，更應該去核查接收流量的類型。再次運行Wireshark和Chrome調試工具，在Chrome控制台可以看到如下內容：
這一次沒有數據包進進出出，也沒有通過HTTP協議傳輸的圖片。現在我們看到的是Websocket數據幀，大部分是保持Websocket會話連通性的ping/pong幀。比較有趣的幀是connect，prepareRtspSession和onReadyToPlay－——連接服務器正是要經歷這些階段：首先建立Websocket連接和會話，然后播放請求內容。
下面是chrome://webrtc-internals所示內容：
如上圖所示，來自網絡攝像頭的視頻碼率為1Mbps。也有發送流量，主要是RTCP和ICE數據包。瀏覽器和Amazon服務器之間的RTT在300ms左右。
現在我們來看Wireshark，它清楚顯示來自服務器的UDP流量。圖片數據包大小為1468字節，這就是WebRTC流量。特別地，我們可以從瀏覽器中看到傳輸VP8視頻幀的SRTP數據包。另外，我們也可以看到一些STUN請求，這是WebRTC在仔細檢查連接狀況。
值得一提的是視頻播放延遲很低。WebRTC工作在SRTP/UDP之上，相比於HTTP、RTMP和其它基於TCP的協議，這是最快的發送數據包方法。因此，可見延遲是RTT 、緩沖區時延、解碼時延、播放時延的總和。
從視覺上講，裸眼沒有感覺到任何延遲，這表示延遲低於500ms。
下一個測試是連接其他觀眾。我們打開10個Chrome窗口，每個窗口都播放視頻，這讓Chrome變得遲鈍。在另一台電腦上打開第11個窗口，視頻播放仍然很流暢。
移動設備的WebRTC
正如你所知，Android平台上的Chrome和Firefox也都支持WebRTC。讓我們檢查WebRTC廣播在這里是否工作：
如上圖所示，一部HTC智能機在Firefox上播放來自網絡攝像頭的視頻。和桌面系統相比，移動設備上的視頻播放同樣很平滑流暢。
結論
作為結果，我們能夠以最小代價把網絡攝像頭的視頻用WebRTC廣播到瀏覽器。實現這一切不需要雨中跳舞或者巫術，也不需要火箭科學，僅基礎Linux和SSH知識即可。
廣播質量完全可以接受，裸眼感覺不到延遲。
我們可以得出結論：基於瀏覽器的WebRTC廣播完全值得考慮，正如在我們的場景下，WebRTC不是附件或者插件，而是一個在瀏覽器中播放視頻的真正平台。
為什么WebRTC沒有被廣泛應用
主要障礙可能在於缺少視頻編解碼器。WebRTC社區和廠商應該努力把H.264集成到WebRTC中。我們不能說VP8不好，但是為什么要忽視數百萬計已經使用H.264的兼容設備和軟件呢？該死的專利！
第二個原因是只有部分瀏覽器支持WebRTC。IE和Safari瀏覽器仍然不支持，因此我們不得不用其它辦法比如使用webrtc4all插件。
在未來我們希望能夠看到很多不需要轉碼的解決方案，和很多能夠從不同設備播放視頻流的瀏覽器。
譯者：weizhenwei，具體詳見:【編風網】