策劃 / 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太麻煩，搜索一下就能用的場景，比如遠程車險定損、在線視頻客服等等，這些惠民便民的場景也是微信非常鼓勵和推薦的。

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