1.官方網站:
http://sites.google.com.sixxs.org/site/webrtc/home
http://sites.google.com.sixxs.org/site/webrtc/reference/webrtc-components
http://sites.google.com.sixxs.org/site/webrtc/reference
http://code.google.com.sixxs.org/p/webrtc/source/checkout
http://sites.google.com.sixxs.org/site/webrtc/reference/getting-started
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
【介紹性】
WebRTC應該是基於Google在去年收購的GIPS技術，其實在收購之前GIPS就製作了Android、Windows Mobile和iOS版的VideoEngine，可實現跨設備的實時聊天標準。
Chrome、Firefox和Opera未來都將支持WebRTC
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://www.infoq.com.sixxs.org/cn/news/2011/06/google-webrtc
Google開源實時通信項目WebRTC
作者 崔康 發佈於 2011年6月3日
最近，Google正式開源了WebRTC實時通信項目，希望瀏覽器廠商能夠將該技術內建在瀏覽器中，從而使Web應用開發人員能夠通過HTML標籤和JavaScript API就實現Web音頻、視頻通信功能。
WebRTC（Web Real Time Communication）並不是Google原來自己的技術。在2010年，Google以大約6820萬美元收購了VoIP軟件開發商Global IP Solutions公司，並因此獲得了該公司擁有的WebRTC技術。如今，互聯網的音頻、視頻通信服務技術一般都是私有技術，如Skype， 需要通過安裝插件或者桌面客戶端來實現通信功能。Google希望Web開發人員能夠直接在瀏覽器中創建視頻或語音聊天應用，Global IP Solutions公司之前已經針對Android、Windows Mobile、iPhone製作了基於WebRTC的移動客戶端。Google此次將WebRTC開源出來，就是希望瀏覽器廠商能夠將該技術直接內嵌到瀏 覽器中，從而方便Web開發人員。
WebRTC的博客說明了WebRTC的優勢和發展方向：
直到現在，實時通信仍然需要私有的信號處理技術，大部分都是通過插件和客戶端來安裝使用。我們通過WebRTC開源了收購GIPS後獲得的音頻、視頻引擎技術，讓開發人員能夠了解信號處理技術，並使用了BSD風格的授權。這會支持開發人員通過簡單的HTML和JavaScript API創建音頻和視頻聊天應用。
我們正在與其他瀏覽器開發廠商Mozilla和Opera等緊密合作，儘快在瀏覽器中實現這項技術以便於Web社區使用。此外，我們還積極地參與IETF和W3C工作組的活動，定義和實現一套實時通信標準。
其官網上列表了使用WebRTC技術的四個理由：
- 互聯網成功的一個關鍵因素是一些核心技術如HTML、HTTP和TCP/IP是開放和免費實現的。目前，在瀏覽器通信領域還沒有免費、高質量、完整的解決方案。WebRTC就是這樣的技術。
- 該技術已經集成了最佳的音頻、視頻引擎，並被部署到數以百萬級的終端中，經過超過8年的磨練。Google不會從該技術中收取費用。
- 包含了使用STUN、ICE、TURN、RTP-over-TCP的關鍵NAT和防火牆穿越技術，並支持代理。
- 構建在瀏覽器中，WebRTC通過提供直接映射到PeerConnection的信號狀態機來抽象信號處理。Web開發人員因此可以選擇適合應用場景的協議（例如：SIP、XMPP/Jingle等等）。
WebRTC的架構圖如下所示：
圖 1 WebRTC架構圖（圖片來源：WebRTC官方網站）
關於架構圖的組成部分，包括：
Web API——第三方開發人員用來開發基於Web的應用，如視頻聊天。
WebRTC Native C++ API——瀏覽器廠商用於實現Web API的函數集。
Session Management——抽象session層，支持調用構建和管理層，由應用開發者來決定如何實現協議。
VoiceEngine——音頻媒體鏈的框架，從聲卡到網絡。
iSAC——一種用於VoIP和流音頻的寬帶和超寬帶音頻編解碼器，iSAC採用16 kHz或32 kHz的採樣頻率和12—52 kbps的可變比特率。
iLBC——用於VoIP和流音頻的窄帶語音編解碼器，使用8 kHZ的採樣頻率，20毫秒幀比特率爲15.2 kbps，30毫米幀的比特率爲13.33 kbps，標準由IETF RFC 3951和3952定義。
NetEQ for Voice——動態抖動緩存和錯誤隱藏算法，用於緩解網絡抖動和丟包引起的負面影響。在保持高音頻質量的同時儘可能降低延遲。
VideoEngine——視頻媒體鏈的框架，從相機像頭到網絡，從網絡到屏幕。
VP8——來自於WebM項目的視頻編解碼器，非常適合RTC，因爲它是爲低延遲而設計開發的。
Image enhancements——消除通過攝像頭獲取的圖片的視頻噪聲等。
其他更詳細的架構分析可以查看這裏的文檔。
PeerConnection位於WebRTC Native C++ API的最上層，它的代碼實現來源於libjingle（一款p2p開發工具包），目前被應用於WebRTC中。其中關鍵的兩個類定義是：
class PeerConnectionObserver {
public:
virtual void OnError();
virtual void OnSignalingMessage(const std::string& msg);
virtual void OnAddStream(const std::string& stream_id,
int channel_id,
bool video);
virtual void OnRemoveStream(const std::string& stream_id,
int channel_id,
bool video);
};該類定義了一個抽象的觀察者。開發人員應該繼承實現自己的觀察者類。
class PeerConnection {
public:
explicit PeerConnection(const std::string& config);
bool Initialize();
void RegisterObserver(PeerConnectionObserver* observer);
bool SignalingMessage(const std::string& msg);
bool AddStream(const std::string& stream_id, bool video);
bool RemoveStream(const std::string& stream_id);
bool Connect();
void Close();
bool SetAudioDevice(const std::string& wave_in_device,
const std::string& wave_out_device);
bool SetLocalVideoRenderer(cricket::VideoRenderer* renderer);
bool SetVideoRenderer(const std::string& stream_id,
cricket::VideoRenderer* renderer);
bool SetVideoCapture(const std::string& cam_device);
};具體的函數說明可以查看相應的API介紹。
正如Google所說的，它一直在參與制定和實現HTML 5標準中的視頻會議和p2p通信部分，雖然還不是正式標準，但是我們可以從草案的示例中看到未來Web開發人員的使用情況：
// the first argument describes the STUN/TURN server configuration
var local = new PeerConnection('TURNS example.net', sendSignalingChannel);
local.signalingChannel(...); // if we have a message from the other side, pass it along here
// (aLocalStream is some GeneratedStream object)
local.addStream(aLocalStream); // start sending video
function sendSignalingChannel(message) {
... // send message to the other side via the signaling channel
}
function receiveSignalingChannel (message) {
// call this whenever we get a message on the signaling channel
local.signalingChannel(message);
}
local.onaddstream = function (event) {
// (videoElement is some <video> element)
videoElement.src = URL.getObjectURL(event.stream);
};
目前有關Web實時通信的技術標準正在制定當中，W3C的Web Real-Time Communication工作組今年五月份剛剛正式成立，並計劃在今年第三季度發佈第一個公開草案，從其工作組的路線圖中可以看出，正式的推薦標準預計將在2013年第一季度發佈，有關W3C標準是否會對WebRTC項目的發展有所影響，未來還要看草案的具體細節。
Google希望開源的WebRTC技術能夠獲得越來越多的瀏覽器廠商支持，WebRTC的網站已經宣佈將在Chrome、Firefox和Opera上實現相應的API接口。Opera首席技術官Håkon Wium Lie對媒體表示，Google能夠把價值不菲的代碼貢獻出來非常了不起，Opera一直希望能夠在瀏覽器中實現實時通信技術。
提到實時通信技術，不得不讓人想起行業巨頭Skype。巧合的是，就在前不久，微軟剛剛斥資85億美元現金收購網絡電話服務商Skype，當時有許多分析師指出，微軟的收購將直面Google的競爭：
…...收購也挫敗了競爭對手Google利用Skype技術完善通話服務的計劃。
MSN即時通訊、必應（bing）搜索、網絡廣告等成了微軟在互聯網領域迎戰谷歌的三大陣地。然而，相對於谷歌在互聯網行業的呼風喚雨，微軟的互聯網戰略一直沒有真正展現出讓業界看到其能夠挑戰谷歌的核心優勢。
谷歌和蘋果都已經在網絡電話上投入了數年時間。蘋果一直在力推iChat和FaceTime，谷歌也在普及其網絡通信相關產品Chat和Voice。不過，谷歌和蘋果都有一個共同的問題，他們很難在競爭對手的平臺上生存。蘋果用戶無法和谷歌以及微軟的用戶進行視頻聊天，谷歌在跨 平臺方面做了很多努力，但是仍有不少障礙。
不過Skype則沒有這一問題，作爲免費服務的Skype可以運行在蘋果、Linux以及Windows電腦上，也支持Android和iPhone等手機平臺，甚至可以在電視機上運行。
收購Skype，微軟不僅僅是爲了從中受益，微軟還希望藉此使Skype遠離谷歌的“魔爪”。如果谷歌收購了Skype，這對微軟來說無疑是一個沉重的打擊。想想吧，如果谷歌收購了Skype，並將Skype整合進Google Apps、Gmail、Google Talk和Google Voice等谷歌產品之中，再想想如果谷歌將Skype與Android平臺進行一些深度整合，這對微軟來說，無疑是一場災難。即便微軟並未很好的將Skype整合進自家產品之中，但這也避免了谷歌通過收購Skype來獲得巨大的價值。
就在微軟收購Skype不久，Google就宣佈對WebRTC開源，這不免讓人有所聯想。有國外媒體評論說，Google此次開源是想讓廣大用戶遠離該行業的領導者如Skype和Apple的FaceTime平臺。通過瀏覽器來支持實時通信技術，Google希望開發社區能夠在自己的應用中集成該功能，從而削弱其他對手。
這已經不是Google第一次大方地開源關鍵項目。去年，Google曾經將VP8視頻編解碼項目開源，以支持HTML 5技術中的視頻媒體播放。如今，多種主流瀏覽器都已經支持VP8格式，成爲主要的多媒體格式，相比伴隨着專利、付費糾紛的H.264，開放、免費的VP8更讓瀏覽器廠商放心。
這次WebRTC的開源會對瀏覽器廠商和實時通信技術領域帶來哪些影響，InfoQ中文站將持續關注和及時報道，也歡迎讀者朋友發表自己的看法。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
系列好文：
。
。
。
WebRTC的video_engine系統架構圖，如下：
1. WebRTC提供了一個框架，對於視頻部分而言，已經解決了從視頻採集、編碼、傳輸、顯示的全部功能。
在架構圖中，有顏色的箭頭表示了視頻流的數據流向：從視頻採集端開始，經過網絡傳輸層，再到視頻接收端。
2. WebRTC的系統限制：
Device Manager最大可以管理10個輸入設備；ChannelManager最大可以管理4個Channel；當然，你也可以修改這些最大值的。
Codec支持的最大分辨率是1920*1200。
3. WebRTC的擴展
WebRTC不是一個封閉的系統，相反，它很容易擴展，包括Device，Codec,Render，Transport，都提供了可擴展的接口。
比如，可以增加H264的Codec，以方便加入對現有系統的支持。
對於視頻會議，可以擴展網絡傳輸層：當從視頻採集端得到編碼後的數據包時，直接通過視頻會議的網絡傳輸，由視頻會議服務器發送到各個視頻會議客戶端，再交給WebRTC進行接收處理。這就達到了我們想要的功能。