小程式音視訊能力技術負責人解讀“小程式直播”

策劃 / LiveVideoStack

責編 / 包研

一夜之間，“小程式+直播”成為多媒體開發者熱議的話題。從底層技術實作到接口開放程度，是否綁定騰訊雲？價格體系？低延遲性能如何？......一連串的問題背後是開發者乃至整個生态對“小程式+直播”的關注。LiveVideoStack邀請到小程式音視訊能力的技術負責人常青，就開發者關注的各種問題進行了解答。如果您還有新的問題，請在在文末留言或郵件至[email protected]。

另外，我們還發起了針對“小程式+直播”的問卷，近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太麻煩，搜尋一下就能用的場景，比如遠端車險定損、線上視訊客服等等，這些惠民便民的場景也是微信非常鼓勵和推薦的。

點選【閱讀原文】，完成問卷，即可以看到最新的投票資料。