H5和WebRTC實時通信方案對比

目前，實時音視頻通信的實現方案在瀏覽器上有兩種，分別是H5和WebRTC，前者能夠拉流觀看，後者能夠實現推流和拉流。

正文

在瀏覽器上實現音視頻實時通信，H5和WebRTC是兩種可選方案，可是兩者有明顯的區別，優劣也比較突出。

H5的實時通信方案

瀏覽器H5的實時方案有明顯的優點和劣勢，優點是開發成本比較低，開發週期短，劣勢是隻能拉流，不能推流，不能實現互動連麥。另外，瀏覽器H5方案延遲比較大。

若是使用RTMP或者HTTP-FLV協議，延遲會在1秒到3秒之間，若是使用HLS協議延遲會更大，固然也能夠經過限制ts分片大小實現較低的延時，太大的延遲是不適合作直播連麥的。可是對於相似大班課和會議的場景，上述媒體協議都是適合的，由於音視頻流是單向的，沒有延時上感知。

WebRTC的實時通信方案

儘管瀏覽器H5方案很是廣泛，開發方便可是不能連麥直播。那麼在瀏覽器上能不能實現連麥直播呢？答案是確定的，它就是WebRTC。最先是由谷歌發起的P2P實時通信方案，在Chrome瀏覽器上進行了長期而普遍的驗證，目前不少瀏覽器都已經支持了WebRTC。

WebRTC包括了音頻引擎，視頻引擎、傳輸引擎等，其中，音頻引擎包括了兩個編解碼器：iSAC和iLBC，前者針對寬帶和超寬帶的音頻編解碼，後者針對窄帶音頻編解碼，其實就是Opus音頻編碼。音頻引擎還包括了回聲消除、噪音抑制和自動增益模塊。視頻引擎包括了VP8和VP9的視頻編解碼器，目前谷歌正打算推出AV1。視頻引擎還包括視頻抖動緩衝和圖像質量加強等模塊。傳輸引擎的話，WebRTC使用SRTP（Secured Realtime Transport Protocol）進行音視頻實時的安全傳輸。其中，密鑰的生成依賴於DTLS協議的協商過程。

一樣，瀏覽器WebRTC方案也有本身的不足：

1）沒有自定義模塊設置接口，在瀏覽器端不能實現較好的美顏和貼圖效果。

2）WebRTC沒有統一的信令標準，一方面給了技術方案的靈活性，另外一方面也形成多系統互通時的轉換成本。

3）音頻編碼格式和視頻編碼格式必須依靠WebRTC，不能自行定製化。

4）不少流瀏覽器支持WebRTC不是很友好，存在差別性。