開(kāi)發(fā)者需要了解實(shí)時(shí)音視頻技術(shù)選型中要避開(kāi)的坑點(diǎn)，以便提高開(kāi)發(fā)集成效率。具體來(lái)說(shuō)，以下四個(gè)方面要綜合考慮。
一、實(shí)時(shí)音視頻與IM能力不宜分散
幾乎100%的實(shí)時(shí)音視頻在線(xiàn)應用都有文字/語(yǔ)音消息、文件傳輸、圖片顯示等IM需求。
目前市場(chǎng)上PaaS服務(wù)商這兩方面能力強弱不一：有的大廠(chǎng)雖然兩方面能力都提供，但不能確保兩種能力同樣高質(zhì)量；有的專(zhuān)業(yè) RTC 廠(chǎng)商，只能提供RTC能力，IM能力還得由第三方專(zhuān)業(yè)服務(wù)商提供。
這樣，便迫使開(kāi)發(fā)者在集成過(guò)程中不得不分別選擇服務(wù)商。當實(shí)時(shí)音視頻與IM質(zhì)量不穩定時(shí)，需要逐一協(xié)調各個(gè)服務(wù)商，逐一排查問(wèn)題，無(wú)形中增加了后期的運營(yíng)成本。其實(shí)，IM和音視頻在很多場(chǎng)景下有耦合，建議開(kāi)發(fā)者在選型一開(kāi)始就要考慮具有RTC+IM雙重高保障能力的通信云廠(chǎng)商，盡量“用一套 SDK,解決所有通信場(chǎng)景”。
對開(kāi)發(fā)者來(lái)說(shuō)兩項功能同時(shí)開(kāi)發(fā)，開(kāi)發(fā)包相對比較小；如果前期只用到了IM,沒(méi)有用到RTC,那么只需要學(xué)習IM方面的開(kāi)發(fā)文檔就可以了，一旦有了RTC需求，再去學(xué)習RTC文檔，開(kāi)發(fā)者只需接入相關(guān)接口，快速與IM能力做對接和匹配，即可完成兩類(lèi)功能在A(yíng)pp生命周期里的全覆蓋。
除了開(kāi)發(fā)上的易快速上手外，選擇“IM+RTC+推送”整合的解決方案，開(kāi)發(fā)者還可以享受一致的網(wǎng)絡(luò )架構，提高傳輸的效率和質(zhì)量，獲得一致的服務(wù)保障。例如，融云近期升級了實(shí)時(shí)音視頻能力，RTC的通信信令是復用IM信令通道，可以確保消息100%的連通率和到達率，使底層的通信優(yōu)勢發(fā)揮到最大。
二、延時(shí)、卡頓、抖動(dòng)的質(zhì)量問(wèn)題要解決好
通過(guò)調研發(fā)現，用戶(hù)最不能接受實(shí)時(shí)音視頻的三個(gè)質(zhì)量問(wèn)題是延時(shí)、卡頓、抖動(dòng)。
低延時(shí)要靠?jì)蓚�(gè)方面解決，一個(gè)是傳輸協(xié)議，一個(gè)是優(yōu)化整體傳輸環(huán)節。實(shí)時(shí)音視頻的主流傳輸協(xié)議有RTMP和UDP兩種，一種支持CDN技術(shù)，一種支持WebRTC技術(shù)，相對來(lái)說(shuō)，CDN技術(shù)延時(shí)性在3-5秒，WebRTC可以在幾百毫秒以?xún)龋F在很多廠(chǎng)商可以同時(shí)支持這兩種技術(shù)，分別適用于不同的場(chǎng)景。
整體傳輸環(huán)節中，采集/渲染、編解碼/網(wǎng)絡(luò )往返都會(huì )有一定的延時(shí)，有些是硬件的物理延遲，需要靠5G這樣底層網(wǎng)絡(luò )技術(shù)的提升，或者布更多的數據中心、邊緣結點(diǎn)，便于就近接入；有些要針對實(shí)際場(chǎng)景，在具體形態(tài)上做一些權衡，比如在處理粒度上粗細的考慮，越細的粒度傳輸的數據包相對較大，延遲也會(huì )更高。
當音視頻出現卡頓時(shí)，有一個(gè)視頻流暢優(yōu)先的原則。我們通過(guò)降低一些碼率和幀率，即使畫(huà)面模糊一點(diǎn)，也要讓用戶(hù)視覺(jué)上是流暢不卡頓的。這樣在選型時(shí)候，要考慮幾個(gè)方面：一個(gè)是優(yōu)化低碼率下的視頻清晰度；二是要有帶寬估算能力，當預判到這個(gè)帶寬沒(méi)法承受高清晰視頻傳輸時(shí)，自動(dòng)轉化成低碼率并通過(guò)優(yōu)化算法，使低碼率視頻清晰度能媲美高清視頻。
另外，數據包通常會(huì )以錯誤的順序到達，從而產(chǎn)生抖動(dòng)相關(guān)問(wèn)題，或者直接丟失，造成音視頻空白。谷歌一份資料顯示，視頻聊天應用 Duo 99%的通話(huà)都有數據包丟失、過(guò)度抖動(dòng)或網(wǎng)絡(luò )延遲情況。20%的通話(huà)丟失了超過(guò)3%的音頻，10%的通話(huà)丟包率超過(guò)8%,也就是說(shuō)每次通話(huà)都有很多音頻需要替換。
處理上述問(wèn)題，很多廠(chǎng)商會(huì )采用抗丟包及抗網(wǎng)絡(luò )抖動(dòng)能力的NACK（丟包重傳）、FEC（前向糾錯）、自適應帶寬調整（動(dòng)態(tài)調整碼）、接收端 Jitter Buffer（媒體流平穩）等各種機制，有些是組合使用，有些是單獨使用，開(kāi)發(fā)者在選型前一定要做到深入了解。
三、擁有全球通信和場(chǎng)景化能力
剛才談到低延時(shí)、抗丟包的解決策略，有些是與網(wǎng)絡(luò )接入路徑長(cháng)短直接相關(guān)的。比如中美兩地的音視頻連接，沒(méi)有全球通信網(wǎng)絡(luò )支持、數據中心和節點(diǎn)布局的廠(chǎng)商是提供不了服務(wù)的。開(kāi)發(fā)者選型開(kāi)發(fā)前，就要考慮到自己業(yè)務(wù)的所屬范圍。
選擇全球化服務(wù)的云廠(chǎng)商，除了看數據中心和節點(diǎn)分布外，還要仔細考察全球網(wǎng)絡(luò )布局的品質(zhì)，簡(jiǎn)單說(shuō)，有的廠(chǎng)商提供了全球網(wǎng)絡(luò )優(yōu)化能力，中美之間的音視頻連接在未優(yōu)化前要經(jīng)過(guò) 100 多跳，而優(yōu)化后僅 6 跳就能完成連通。這是由于，這些廠(chǎng)商擁有自有的路徑最優(yōu)算法，通過(guò)智能路由就近接入，即使在異國/地網(wǎng)絡(luò )環(huán)境較差的情況下，仍然能夠及時(shí)切換到更好的線(xiàn)路上去。比如融云擁有全球優(yōu)化加速網(wǎng)絡(luò )，實(shí)時(shí)音視頻通話(huà)可做到全球端到端延時(shí)小于400ms,最低延時(shí)66ms,保障端到端之間延遲無(wú)感知的實(shí)時(shí)互動(dòng)。
在場(chǎng)景化能力上，實(shí)際上相比IM,實(shí)時(shí)音視頻更加通道化，在各個(gè)場(chǎng)景中復用的程度也相對較高，能力也更基礎。優(yōu)秀的PaaS廠(chǎng)商會(huì )按場(chǎng)景提供不同的Demo,音視頻技術(shù)的升級也針對解決更多的應用場(chǎng)景去優(yōu)化，便于開(kāi)發(fā)者拿來(lái)即用，這種方式對入門(mén)級的開(kāi)發(fā)者都十分友好。各種API接口相對獨立，開(kāi)發(fā)者只需關(guān)注和使用所需要的SDK,就可以實(shí)現想要的場(chǎng)景，大大降低集成開(kāi)發(fā)的難度。
四、開(kāi)發(fā)者服務(wù)足夠完善
在一些社區中，我們常常會(huì )看到一些技術(shù)文檔下，開(kāi)發(fā)者提出問(wèn)題而沒(méi)有回復。開(kāi)發(fā)者為提高開(kāi)發(fā)效率，越來(lái)越傾向于自助完成工作，因此，開(kāi)發(fā)文檔是否易懂，Demo 是否易用，都顯得十分重要。
另外，工單回復的速度，微信群、社區的值守和響應程度等都能反映PaaS廠(chǎng)商服務(wù)意識的強弱。通常來(lái)說(shuō)，7×24小時(shí)技術(shù)支持服務(wù)，1小時(shí)工單快速回復、快速遠程接入、快速恢復的故障應急響應機制，這些都是對開(kāi)發(fā)者很完善的服務(wù)支持。
有些廠(chǎng)商還會(huì )提供特色的質(zhì)量監控服務(wù)，比如融云“北極星”的質(zhì)量問(wèn)題排查平臺，通過(guò)可視化圖表，快速定位卡頓位置，實(shí)時(shí)統計丟包率，使開(kāi)發(fā)者可以自助排查每一次音視頻通話(huà)過(guò)程中的丟包率、網(wǎng)絡(luò )帶寬等通信技術(shù)參數。可以直接定位用戶(hù)問(wèn)題，提高排查效率，提升用戶(hù)體驗。
