一夜之間,“小程序+直播”成為多媒體開發(fā)者熱議的話題。從底層技術(shù)實現(xiàn)到接口開放程度,是否綁定騰訊云?價格體系?低延遲性能如何?......一連串的問題背后是開發(fā)者乃至整個生 ...
?
一夜之間,“小程序+直播”成為多媒體開發(fā)者熱議的話題。從底層技術(shù)實現(xiàn)到接口開放程度,是否綁定騰訊云?價格體系?低延遲性能如何?......一連串的問題背后是開發(fā)者乃至整個生態(tài)對“小程序+直播”的關(guān)注。LiveVideoStack邀請到小程序音視頻能力的技術(shù)負責人常青,就開發(fā)者關(guān)注的各種問題進行了解答。如果您還有新的問題,請在在文末留言或郵件至editors@livevideostack.com。另外,我們還發(fā)起了針對“小程序+直播”的問卷,近9成的開發(fā)者看好“小程序+直播”,最看好的應用場景是直播、在線教育和視頻會議,最關(guān)心的性能是延遲。
常青:小程序的RTC能力是基于RTMP技術(shù)實現(xiàn)的,沒有使用WebRTC是出于兩方面的考慮:一是微信安裝包(尤其是iOS版本)的體積增量必須要控制在可接受的范圍內(nèi),這是一個硬性的要求。另一個考慮就是RTMP協(xié)議的適用場景更多,除了實時視頻通話場景之外,還可以做標準直播解決方案。比如培訓、教育等場景。
常青:首先,對于直播場景下音視頻通道的加密是很剛需的一個要求,所以小程序在RTC模式下如果走騰訊云,會默認開啟加密能力以避免竊聽攻擊。
當然,小程序如果實現(xiàn)RTC不需要綁定騰訊云,關(guān)于這一點大家可以做個試驗:簡單用 nginx-rtmp 搭建一個后臺服務器,然后創(chuàng)建兩對RTMP url,按照文檔 https://cloud.tencent.com/doc... 的指引放在小程序里測試,可以體驗一下效果,只要網(wǎng)絡不是特別差,延遲和效果應該是很不錯的。
騰訊云真正做的出色的是,讓全國不同地方的兩路RTMP,都能達到很好的效果,這是騰訊云多年來一直積累CDN節(jié)點,優(yōu)化內(nèi)部鏈路調(diào)度(GBN網(wǎng)絡)的結(jié)果。
常青:RTMP本身是可靠的傳輸層協(xié)議,所以不需要實現(xiàn)ARQ和FEC算法,ARQ和FEC都是為了解決傳輸層協(xié)議不可靠(比如私有UDP協(xié)議)而不得不采用的辦法。
這是一個漫長的故事:早期實時音視頻通話面對的網(wǎng)絡條件要比現(xiàn)在惡劣的多,也就是常說的窄帶時代。在那個時代的網(wǎng)絡條件下,由于帶寬成本極高,所以實時音視頻通話都需要采用 UDP 協(xié)議來打洞實現(xiàn) peer to peer 直連,這就意味著我們只能選擇 UDP 協(xié)議,因為 TCP 打洞做NAT穿越不是那么容易。而 UDP 協(xié)議如果做成可靠的協(xié)議(也就是不丟包),就喪失了它的靈活性,因為音視頻通話本身對于部分數(shù)據(jù)的丟失是可以容忍的,所以適當?shù)脑试S一些丟包是更加符合窄帶傳輸?shù)男枨?。當然,我們不希望頻繁的丟數(shù)據(jù),不然通話質(zhì)量就上不來了,所以 ARQ 和 FEC 這種丟包恢復技術(shù)就應用而生了。
時代在進步,技術(shù)思路也在進步。目前已經(jīng)到了寬帶時代,高清大碼率的場景越發(fā)普遍,直播的流行和大王卡的普及,都在告訴我們網(wǎng)絡的帶寬越來越理想,所以我們現(xiàn)在面對的主要問題可能不再是帶寬不夠用,而是WiFi 和 4G下突發(fā)的網(wǎng)絡波動。而應對這種網(wǎng)絡波動,可靠傳輸層協(xié)議并不比私有UDP協(xié)議劣勢太多,而且ARQ和FEC本身會產(chǎn)生帶寬的浪費,以FEC為例,30%的丟包需要用30%的冗余來解決,但是30%的冗余就意味著多傳輸30%的數(shù)據(jù),在碼率小的時候不起眼,大碼率場景下就越發(fā)雞肋了。
所以,用慣了ARQ和FEC的技術(shù)專家們,也可以偶爾考慮一下可靠的傳輸協(xié)議,只要不是特別極端的場景,效果還是可以一試的,而且我們也在持續(xù)優(yōu)化和改進,爭取在每一個版本中都有效果上的提升。
騰訊云也有專門的私有UDP解決方案,其ARQ和FEC技術(shù)也非常成熟,但這都是騰訊云自家的標準,在微信小程序里落地就會面臨綁定騰訊云的問題,所以我們最終選擇了普遍支持的標準RTMP協(xié)議,并將底層的TCP傳輸層換成了業(yè)內(nèi)目前普遍更被看好的HTTP/2的一種內(nèi)部傳輸技術(shù),它也是基于UDP協(xié)議實現(xiàn)的,但它并不私有,也越來越流行。如果您感興趣,Google一下 HTTP/2 會了解到更多。
常青:小程序的定位就是服務號的能力擴展,它的優(yōu)勢就是能力的擴展上要比H5更快,H5受限于瀏覽器內(nèi)核的普及,新特性和新能力的上線需要一個較長的時間,而且蘋果在這里的態(tài)度也有很大的不確定性。比如最近WebRTC持續(xù)升溫,很大程度上要得益于蘋果的態(tài)度轉(zhuǎn)變,而我們并不能假設在后續(xù)所有的場景上蘋果都會保持這種開放的心態(tài)。同時,小程序的定位更加專注于能力實現(xiàn),在體驗和二次加載速度上,相比于H5還是有一定的優(yōu)勢。當然,相比于定制性和迭代速度,體驗上的優(yōu)勢僅僅是一個小細節(jié)了。
常青:目前iOS上的WebRTC能力還有一些不盡如人意的地方。另外,Android系統(tǒng)下的WebRTC實現(xiàn)也因為系統(tǒng)版本和碎片化問題有很多兼容性問題。在目前這段WebRTC還在不斷完善中的時間里,要做到比較統(tǒng)一的體驗,前端工程師們依然要面對很多不可控因素。
從長期來看,小程序上的優(yōu)勢在于更好的可控性和可定制性:可控性上來講,由于審核制度的存在,在小程序里出現(xiàn)涉黃涉政等不法現(xiàn)象的概率會接近于零;另一方面,類似美顏等更“接地氣”的特性的支持,都是WebRTC需要很長時間才能反應過來的,我們也非常希望后續(xù)能夠快速迭代地增加一些高性價比的特性進來(太過娛樂化的特性暫不考慮)。
常青:live-pusher 和 live-player 的RTC模式本身自帶回音消除功能,只要設置好mode參數(shù)為RTC,都是可以使用回聲消除能力的。 而且 live-pusher 和 live-player 沒有限制第三方云服務,只要有可用的RTMP地址就可以使用,至于如何基于 live-pusher 和 live-player 標簽實現(xiàn)實時通話功能,可以參考:https://cloud.tencent.com/doc...
常青:小程序此次開放的音視頻能力確實不需要指定騰訊云,支持RTMP協(xié)議的云商都可以對接,所有接口都已經(jīng)放在了文檔 https://cloud.tencent.com/doc... 和https://cloud.tencent.com/doc... 中進行說明,沒有尚未暴露的接口。
常青:如果使用 live-player 標簽,可以使用RTMP協(xié)議和http-flv協(xié)議進行接入,也可以使用HLS協(xié)議接入,但HLS協(xié)議需要使用微信小程序早就開放的<video>標簽。
常青:這里第三方的相關(guān)服務要看是云服務還是終端服務了。如果是云服務,那是完全沒有問題的,支持RTMP協(xié)議都可以(接入),比如連麥、CDN等都無限制。但如果是終端服務,除非是JavaScript的組件,否則都是不行的,因為微信小程序只提供了JavaScript的編程能力。美顏是我們直接將圖像處理算法打包進微信APP實現(xiàn)的,JavaScript無法達到這個計算性能的要求。
常青:小程序的定位就是服務號的能力擴展,最佳的應用場景就是裝APP太麻煩,搜索一下就能用的場景,比如遠程車險定損、在線視頻客服等等,這些惠民便民的場景也是微信非常鼓勵和推薦的。