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