小程序音視頻能力技術負責人解讀「小程序直播」

​

 

策劃 / LiveVideoStack

責編 / 包研

 

一晚上之間，「小程序+直播」成爲多媒體開發者熱議的話題。從底層技術實現到接口開放程度，是否綁定騰訊雲？價格體系？低延遲性能如何？......一連串的問題背後是開發者乃至整個生態對「小程序+直播」的關注。LiveVideoStack邀請到小程序音視頻能力的技術負責人常青，就開發者關注的各類問題進行了解答。若是您還有新的問題，請在在文末留言或郵件至editors@livevideostack.com。

 

另外，咱們還發起了針對「小程序+直播」的問卷，近9成的開發者看好「小程序+直播」，最看好的應用場景是直播、在線教育和視頻會議，最關心的性能是延遲。

 

LiveVideoStack：關於小程序中的RTC能力，是經過WebRTC實現的（或其餘RTC技術），仍是基於RTMP呢？

 

常青：小程序的RTC能力是基於RTMP技術實現的，沒有使用WebRTC是出於兩方面的考慮：一是微信安裝包（尤爲是iOS版本）的體積增量必需要控制在可接受的範圍內，這是一個硬性的要求。另外一個考慮就是RTMP協議的適用場景更多，除了實時視頻通話場景以外，還能夠作標準直播解決方案。好比培訓、教育等場景。

 

LiveVideoStack：求證下，小程序裏面用的是UDP + RTMP方式來實現RTC的，並且還對協議內容加密了？那是否是意味着小程序RTC必須走騰訊雲？

 

常青：首先，對於直播場景下音視頻通道的加密是很剛需的一個要求，因此小程序在RTC模式下若是走騰訊雲，會默認開啓加密能力以免竊聽攻擊。

 

固然，小程序若是實現RTC不須要綁定騰訊雲，關於這一點你們能夠作個試驗：簡單用 nginx-rtmp 搭建一個後臺服務器，而後建立兩對RTMP url，按照文檔 https://cloud.tencent.com/document/product/454/12521 的指引放在小程序裏測試，能夠體驗一下效果，只要網絡不是特別差，延遲和效果應該是很不錯的。

 

騰訊雲真正作的出色的是，讓全國不一樣地方的兩路RTMP，都能達到很好的效果，這是騰訊雲多年來一直積累CDN節點，優化內部鏈路調度（GBN網絡）的結果。

 

LiveVideoStack：若是是RTMP + UDP，沒法實現ARQ、FEC傳輸算法，是這樣吧？

 

常青：RTMP自己是可靠的傳輸層協議，因此不須要實現ARQ和FEC算法，ARQ和FEC都是爲了解決傳輸層協議不可靠（好比私有UDP協議）而不得不採用的辦法。

 

這是一個漫長的故事：早期實時音視頻通話面對的網絡條件要比如今惡劣的多，也就是常說的窄帶時代。在那個時代的網絡條件下，因爲帶寬成本極高，因此實時音視頻通話都須要採用 UDP 協議來打洞實現 peer to peer 直連，這就意味着咱們只能選擇 UDP 協議，由於 TCP 打洞作NAT穿越不是那麼容易。而 UDP 協議若是作成可靠的協議（也就是不丟包），就喪失了它的靈活性，由於音視頻通話自己對於部分數據的丟失是能夠容忍的，因此適當的容許一些丟包是更加符合窄帶傳輸的需求。固然，咱們不但願頻繁的丟數據，否則通話質量就上不來了，因此 ARQ 和 FEC 這種丟包恢復技術就應用而生了。

 

時代在進步，技術思路也在進步。目前已經到了寬帶時代，高清大碼率的場景愈加廣泛，直播的流行和大王卡的普及，都在告訴咱們網絡的帶寬愈來愈理想，因此咱們如今面對的主要問題可能再也不是帶寬不夠用，而是WiFi 和 4G下突發的網絡波動。而應對這種網絡波動，可靠傳輸層協議並不比私有UDP協議劣勢太多，並且ARQ和FEC自己會產生帶寬的浪費，以FEC爲例，30%的丟包須要用30%的冗餘來解決，可是30%的冗餘就意味着多傳輸30%的數據，在碼率小的時候不起眼，大碼率場景下就愈加雞肋了。

 

因此，用慣了ARQ和FEC的技術專家們，也能夠偶爾考慮一下可靠的傳輸協議，只要不是特別極端的場景，效果仍是能夠一試的，並且咱們也在持續優化和改進，爭取在每個版本中都有效果上的提高。

 

騰訊雲也有專門的私有UDP解決方案，其ARQ和FEC技術也很是成熟，但這都是騰訊雲自家的標準，在微信小程序裏落地就會面臨綁定騰訊雲的問題，因此咱們最終選擇了廣泛支持的標準RTMP協議，並將底層的TCP傳輸層換成了業內目前廣泛更被看好的HTTP/2的一種內部傳輸技術，它也是基於UDP協議實現的，但它並不私有，也愈來愈流行。若是您感興趣，Google一下 HTTP/2 會了解到更多。

 

LiveVideoStack：native的直播、短視頻應用已經很是成熟了，功能強大。同時，基於H5的音視頻應用，在線教育服務也比較流行。那麼小程序具體如何定位本身？他真正的優點在哪裏？

 

常青：小程序的定位就是服務號的能力擴展，它的優點就是能力的擴展上要比H5更快，H5受限於瀏覽器內核的普及，新特性和新能力的上線須要一個較長的時間，並且蘋果在這裏的態度也有很大的不肯定性。好比最近WebRTC持續升溫，很大程度上要得益於蘋果的態度轉變，而咱們並不能假設在後續全部的場景上蘋果都會保持這種開放的心態。同時，小程序的定位更加專一於能力實現，在體驗和二次加載速度上，相比於H5仍是有必定的優點。固然，相比於定製性和迭代速度，體驗上的優點僅僅是一個小細節了。

 

LiveVideoStack：iOS 11能夠支持WebRTC，相信iOS上的微信支持WebRTC也可期。許多開發者看好WebRTC能夠打通iOS、Android和PC瀏覽器。相比而言，小程序的優點是什麼？

 

常青：目前iOS上的WebRTC能力還有一些不盡如人意的地方。另外，Android系統下的WebRTC實現也由於系統版本和碎片化問題有不少兼容性問題。在目前這段WebRTC還在不斷完善中的時間裏，要作到比較統一的體驗，前端工程師們依然要面對不少不可控因素。

 

從長期來看，小程序上的優點在於更好的可控性和可定製性：可控性上來說，因爲審覈制度的存在，在小程序裏出現涉黃涉政等不法現象的機率會接近於零；另外一方面，相似美顏等更「接地氣」的特性的支持，都是WebRTC須要很長時間才能反應過來的，咱們也很是但願後續可以快速迭代地增長一些高性價比的特性進來（太過娛樂化的特性暫不考慮）。

 

LiveVideoStack：是否提供原生的連麥（包含回聲消除）功能？是否開放接口，對接第三方的連麥服務？

 

常青：live-pusher 和 live-player 的RTC模式自己自帶回音消除功能，只要設置好mode參數爲RTC，都是可使用回聲消除能力的。 並且 live-pusher 和 live-player 沒有限制第三方雲服務，只要有可用的RTMP地址就可使用，至於如何基於 live-pusher 和 live-player 標籤實現實時通話功能，能夠參考：https://cloud.tencent.com/document/product/454/12521

 

LiveVideoStack：文檔中表示，小程序音視頻能力不須要指定騰訊雲，但接口彷佛尚未（徹底）開放？

 

常青：小程序這次開放的音視頻能力確實不須要指定騰訊雲，支持RTMP協議的雲商均可以對接，全部接口都已經放在了文檔 https://cloud.tencent.com/document/product/454/12518 和https://cloud.tencent.com/document/product/454/12519 中進行說明，沒有還沒有暴露的接口。

 

LiveVideoStack：CDN有哪幾種接入方式？

 

常青：若是使用 live-player 標籤，可使用RTMP協議和http-flv協議進行接入，也可使用HLS協議接入，但HLS協議須要使用微信小程序早就開放的<video>標籤。

 

LiveVideoStack：第三方服務提供商（如美顏、圖像識別、連麥、CDN等）是否能夠接入小程序，成爲用戶可選的服務？

 

常青：這裏第三方的相關服務要看是雲服務仍是終端服務了。若是是雲服務，那是徹底沒有問題的，支持RTMP協議均可以（接入），好比連麥、CDN等都無限制。但若是是終端服務，除非是JavaScript的組件，不然都是不行的，由於微信小程序只提供了JavaScript的編程能力。美顏是咱們直接將圖像處理算法打包進微信APP實現的，JavaScript沒法達到這個計算性能的要求。

 

LiveVideoStack：小程序接受直播、在線教育、金融、醫療、視頻會議、電商、政務民生等幾類應用的審覈，在您看來，具備音視頻能力的小程序最佳的應用場景是什麼？

 

常青：小程序的定位就是服務號的能力擴展，最佳的應用場景就是裝APP太麻煩，搜索一下就能用的場景，好比遠程車險定損、在線視頻客服等等，這些惠民便民的場景也是微信很是鼓勵和推薦的。