HTML5實時語音通話聊天，MP3壓縮傳輸3KB每秒
- 2019 年 10 月 3 日
- 筆記
自從Recorder H5 GitHub開源庫優化後，對邊錄邊轉碼成小語音片段文件實時上傳伺服器這種操作支援非常良好，因此以前不太好支援的H5語音通話已經有了更好的突破空間。因此花了兩晚時間打造了一個H5語音通話聊天的demo。
一、把玩方法
- 準備區域網內兩台設備(Peer A、Peer B)用最新版本瀏覽器(demo未適配低版本)分別打開demo頁面（也可以是同一瀏覽器打開兩個標籤）
- 勾選頁面中的H5版語音通話聊天，在Peer A中點擊新建連接
- 把Peer A的本機信手動複製傳輸給Peer B，粘貼到遠程資訊中，並點擊確定連接
- 把Peer B自動生成的本機資訊手動複製傳輸給Peer A，粘貼到遠程資訊中，並點擊確定連接
- 雙方P2P連接已建立，使用頁面上方的錄音功能，隨時開啟錄音，音頻數據會實時發送給對方
區域網H5版對講機?
二、技術特性
（1）數據傳輸
github demo中考慮到減少對伺服器的依賴，因此採用了WebRTC P2P傳輸功能，無需任何伺服器支援即可實現區域網內的兩個設備之間互相連接，連接程式碼也算簡單。有伺服器支援可能就要逆天了，不過程式碼也會更複雜。
如果正式使用，可能不太會考慮使用WebRTC，用WebSocket通過伺服器進行轉發可能是最佳的選擇。
WebRTC區域網P2P連接要點（實際程式碼其實差不多，只不過多做了點兼容）：
/******Peer A(本機)******/ var peerA=new RTCPeerConnection(null,null) //開啟會話，等待遠程連接 peerA.createOffer().then(function(offer){ peerA.setLocalDescription(offer); peerAOffer=offer; }); var peerAICEList=[......] //通過peerA.onicecandidate監聽獲得所有的ICE連接資訊候選項，如果有多個網路適配器，就會有多個候選 //創建連接通道對象，A端通過這個來進行數據發送 var peerAChannel=peerA.createDataChannel("RTC Test"); /******Peer B(遠程)******/ var peerB=new RTCPeerConnection(null,null) //連接到Peer A peerB.setRemoteDescription(peerAOffer); //開啟應答會話，等待Peer A確認連接 peerB.createAnswer().then(function(answer){ peerB.setLocalDescription(answer); peerBAnswer=answer; }); //把Peer A的連接點都添加進去 peerB.addIceCandidate(......peerAICEList) var peerBICEList=[......] //通過peerB.onicecandidate監聽獲得所有的ICE連接資訊候選項，如果有多個網路適配器，就會有多個候選 var peerBChannel=... //通過peerB.ondatachannel得到連接通道對象，B端通過這個來進行數據發送 /*******最終完成連接********/ //連接到Peer B peerA.setRemoteDescription(peerBAnswer); //把Peer B的連接點都添加進去 peerA.addIceCandidate(......peerBICEList) /* peerA peerB分別等待peerA/BChannel.onopen回調即完成P2P連接 ，然後通過監聽peerA/BChannel.onmessage獲得對方發送的資訊 ，通過peerA/BChannel.send(data) 發送數據。 */（2）音頻採集和編碼
由於是在我的Recorder庫中新加的demo，因此音頻採集和編碼都是現成的，Recorder庫有好的兼容性和穩定性，因此節省了最大頭的工作量。
編碼最佳使用MP3格式，因為此格式已優化了實時編碼性能，可做到邊錄邊轉碼，16kbps 16khz的情況下可做到2kb每秒的文件大小，音質還可以，實時傳輸時為3kb每秒，15分鐘大概3M的流量。
用wav格式也可以，不過此格式編碼出來的數據量太大，16位 16khz接近50kb每秒的實時傳輸數據，15分鐘要37M多流量。其他格式由於暫未對實時編碼進行優化，使用中會導致明顯示卡頓。
降噪、靜音檢測等高級功能是沒有的，畢竟是非專業人員? 要求高點可以，但不要超出範圍太多啦。
（3）音頻實時接收和播放
接收到一個音頻片段後，本應該是立即播放的，但由於編碼、網路傳輸導致的延遲，可能上個片段還未播放完（甚至未開始播放），因此需要緩衝處理。
因為存在緩衝，就需要進行實時同步處理，如果緩衝內積壓了過多的音頻片段，會導致語音播放滯後太多，因此需要適當進行對數據進行丟棄，實測發現網路正常、設備性能靠譜的情況下基本沒有丟棄的數據。
然後就是播放了，本應是播完一個就播下一個，測試發現這是不靠譜的。因為結束一個片段後再開始播放下一個發出聲音，這個過程會中斷比較長時間，明顯感覺得出來中間存在短暫停頓。因此必須在片段未播完時準備好下一個片段的播放，並且提前開始播放，達到抹掉中間的停頓。
我寫了兩個播放方式：
- 實時解碼播放
- 雙Audio輪換播放
最開始用一個Audio停頓感太明顯，因此用兩個Audio輪換抹掉中間的停頓，但發現不同格式Auido播放差異巨大，播放wav非常流暢，但播放mp3還是存在停頓（後面用解碼的發現是得到的PCM時長變長了，導致事件觸發會出現誤差，為什麼會變長？怪異）。
因此後面寫了一個解碼然後再播放，mp3這次終於能正常連續播放了，wav格式和雙Audio的播放差異不大。實時解碼裡面也用到了雙Audio中的技巧，其實也是用到了兩個BufferSource進行類似的輪換操作，以抹掉兩個片段間的停頓。
不過最終播放效果還是不夠好，音質變差了點，並且多了點噪音。如果有現成的播放程式碼拿過來用就就好了。
三、應用場景
- 數據傳輸改成WebSocket，做個仿微信語音通話H5版還是可以的（受限於Recorder瀏覽器支援）
- 區域網H5版對講機（前端玩具）
- ……沒有想到
完。
