?

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

另外，我(wo)們還發起(qi)了針對“小(xiao)程(cheng)序+直(zhi)播(bo)(bo)”的(de)問卷(juan)，近9成的(de)開(kai)發者看好“小(xiao)程(cheng)序+直(zhi)播(bo)(bo)”，最看好的(de)應用場景是直(zhi)播(bo)(bo)、在線教(jiao)育和視頻(pin)會(hui)議，最關心的(de)性能是延遲。

LiveVideoStack：關于小程序中的RTC能力，是通過WebRTC實現的（或其他RTC技術），還是基于RTMP呢？

常青：小(xiao)程序的RTC能力是基(ji)于RTMP技術實現的，沒(mei)有(you)使用(yong)WebRTC是出于兩方面(mian)的考慮：一是微信(xin)安裝包(bao)（尤(you)其是iOS版本(ben)）的體積增量必須要(yao)控(kong)制(zhi)在(zai)可接受的范圍內，這是一個(ge)硬(ying)性(xing)的要(yao)求。另(ling)一個(ge)考慮就是RTMP協議(yi)的適用(yong)場(chang)(chang)景更多(duo)，除了實時(shi)視頻通(tong)話場(chang)(chang)景之外，還可以(yi)做標準直播解決(jue)方案(an)。比如培(pei)訓、教育等場(chang)(chang)景。

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

常青：首先，對(dui)于直播(bo)場景下音視(shi)頻通道的加密是(shi)很剛(gang)需的一個要求，所以(yi)小程(cheng)序在(zai)RTC模式下如果(guo)走(zou)騰(teng)訊云(yun)，會默(mo)認開啟加密能力以(yi)避免竊聽攻擊(ji)。

當(dang)然，小程(cheng)序(xu)如果(guo)實現(xian)RTC不需要綁定騰訊(xun)云，關于(yu)這一點(dian)大家可以(yi)做(zuo)個試驗：簡單用(yong) nginx-rtmp 搭建一個后臺服務器，然后創建兩對(dui)RTMP url，按照(zhao)文檔 //cloud.tencent.com/doc... 的指引放在小程(cheng)序(xu)里測(ce)試，可以(yi)體(ti)驗一下效(xiao)果(guo)，只要網絡不是(shi)特(te)別差(cha)，延遲和效(xiao)果(guo)應該是(shi)很(hen)不錯的。

騰(teng)訊云真正做(zuo)的(de)出色的(de)是，讓全(quan)國不同地(di)方的(de)兩路(lu)RTMP，都能達到很好的(de)效果(guo)，這(zhe)是騰(teng)訊云多年來一(yi)直積累(lei)CDN節點(dian)，優化內(nei)部鏈路(lu)調度（GBN網絡(luo)）的(de)結果(guo)。

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

常青：RTMP本身是(shi)可(ke)(ke)靠(kao)的傳輸層協(xie)議，所(suo)以(yi)不需要實現ARQ和FEC算法，ARQ和FEC都(dou)是(shi)為(wei)了(le)解決(jue)傳輸層協(xie)議不可(ke)(ke)靠(kao)（比如私有UDP協(xie)議）而不得不采(cai)用(yong)的辦法。

這(zhe)是(shi)(shi)一個漫長的(de)故事：早期實(shi)(shi)時音視頻(pin)通(tong)話面對的(de)網絡條(tiao)件要(yao)(yao)比現(xian)在惡(e)劣(lie)的(de)多(duo)，也(ye)就(jiu)(jiu)是(shi)(shi)常說的(de)窄帶(dai)(dai)時代。在那(nei)個時代的(de)網絡條(tiao)件下，由于帶(dai)(dai)寬(kuan)成(cheng)本(ben)極高，所(suo)以(yi)(yi)實(shi)(shi)時音視頻(pin)通(tong)話都需(xu)要(yao)(yao)采用 UDP 協(xie)(xie)議(yi)來(lai)打洞(dong)實(shi)(shi)現(xian) peer to peer 直連(lian)，這(zhe)就(jiu)(jiu)意(yi)味著(zhu)我(wo)們只能選擇 UDP 協(xie)(xie)議(yi)，因為 TCP 打洞(dong)做NAT穿越(yue)不(bu)(bu)是(shi)(shi)那(nei)么(me)容易。而(er) UDP 協(xie)(xie)議(yi)如果做成(cheng)可(ke)(ke)靠(kao)的(de)協(xie)(xie)議(yi)（也(ye)就(jiu)(jiu)是(shi)(shi)不(bu)(bu)丟(diu)包），就(jiu)(jiu)喪失了它的(de)靈(ling)活(huo)性，因為音視頻(pin)通(tong)話本(ben)身對于部(bu)分數據的(de)丟(diu)失是(shi)(shi)可(ke)(ke)以(yi)(yi)容忍的(de)，所(suo)以(yi)(yi)適當(dang)的(de)允許(xu)一些丟(diu)包是(shi)(shi)更加符合窄帶(dai)(dai)傳輸的(de)需(xu)求(qiu)。當(dang)然(ran)(ran)，我(wo)們不(bu)(bu)希(xi)望頻(pin)繁的(de)丟(diu)數據，不(bu)(bu)然(ran)(ran)通(tong)話質量(liang)就(jiu)(jiu)上不(bu)(bu)來(lai)了，所(suo)以(yi)(yi) ARQ 和 FEC 這(zhe)種(zhong)丟(diu)包恢復技術(shu)就(jiu)(jiu)應用而(er)生了。

時(shi)代在進(jin)步(bu)，技(ji)術(shu)思路也在進(jin)步(bu)。目(mu)前(qian)已經到了寬帶(dai)時(shi)代，高清大碼(ma)率(lv)的(de)(de)(de)場(chang)景越(yue)(yue)發(fa)普遍，直播的(de)(de)(de)流行和(he)大王卡的(de)(de)(de)普及，都在告訴(su)我們(men)(men)網(wang)絡的(de)(de)(de)帶(dai)寬越(yue)(yue)來(lai)越(yue)(yue)理想，所以(yi)我們(men)(men)現在面對的(de)(de)(de)主要(yao)問題可能不再是(shi)帶(dai)寬不夠用，而(er)是(shi)WiFi 和(he) 4G下(xia)突發(fa)的(de)(de)(de)網(wang)絡波動(dong)。而(er)應對這種網(wang)絡波動(dong)，可靠(kao)傳(chuan)輸層(ceng)協議并不比私有UDP協議劣(lie)勢(shi)太多(duo)(duo)，而(er)且(qie)ARQ和(he)FEC本身會產生(sheng)帶(dai)寬的(de)(de)(de)浪(lang)費，以(yi)FEC為例，30%的(de)(de)(de)丟(diu)包需要(yao)用30%的(de)(de)(de)冗余(yu)來(lai)解決(jue)，但(dan)是(shi)30%的(de)(de)(de)冗余(yu)就意味著多(duo)(duo)傳(chuan)輸30%的(de)(de)(de)數據(ju)，在碼(ma)率(lv)小的(de)(de)(de)時(shi)候(hou)不起眼(yan)，大碼(ma)率(lv)場(chang)景下(xia)就越(yue)(yue)發(fa)雞肋了。

所以(yi)，用慣了ARQ和(he)FEC的技術專(zhuan)家們(men)，也可(ke)(ke)以(yi)偶爾考慮一下可(ke)(ke)靠的傳(chuan)輸協(xie)議，只要(yao)不是(shi)特別極端的場景，效(xiao)果還是(shi)可(ke)(ke)以(yi)一試的，而且(qie)我們(men)也在(zai)持續優化和(he)改進(jin)，爭(zheng)取在(zai)每一個版本中都有(you)效(xiao)果上的提升。

騰(teng)(teng)訊(xun)(xun)云(yun)也有(you)專門(men)的(de)私(si)(si)有(you)UDP解(jie)決(jue)方案，其ARQ和FEC技(ji)術(shu)也非常成(cheng)熟，但(dan)這都是騰(teng)(teng)訊(xun)(xun)云(yun)自家的(de)標準，在微信(xin)小程(cheng)序里落(luo)地(di)就會(hui)面(mian)臨綁定(ding)騰(teng)(teng)訊(xun)(xun)云(yun)的(de)問題，所(suo)以我(wo)們最終選(xuan)擇了普遍(bian)(bian)支持的(de)標準RTMP協(xie)議，并將底層的(de)TCP傳(chuan)輸層換成(cheng)了業(ye)內(nei)目前普遍(bian)(bian)更被(bei)看好的(de)HTTP/2的(de)一種(zhong)內(nei)部傳(chuan)輸技(ji)術(shu)，它(ta)也是基于UDP協(xie)議實現的(de)，但(dan)它(ta)并不(bu)私(si)(si)有(you)，也越(yue)來越(yue)流行(xing)。如(ru)果您感興(xing)趣，Google一下(xia) HTTP/2 會(hui)了解(jie)到(dao)更多。

LiveVideoStack：native的直播、短視頻應用已經非常成熟了，功能強大。同時，基于H5的音視頻應用，在線教育服務也比較流行。那么小程序具體如何定位自己？他真正的優勢在哪里？

常青：小(xiao)程序的(de)(de)定位就(jiu)是服務號的(de)(de)能力擴展，它的(de)(de)優(you)勢(shi)就(jiu)是能力的(de)(de)擴展上(shang)(shang)要(yao)比H5更快，H5受限于瀏覽器內核(he)的(de)(de)普及，新特性和新能力的(de)(de)上(shang)(shang)線需(xu)要(yao)一(yi)個較長的(de)(de)時間，而(er)且(qie)蘋果(guo)在這(zhe)里的(de)(de)態(tai)度也有很(hen)大的(de)(de)不確(que)定性。比如最近WebRTC持續升(sheng)溫(wen)，很(hen)大程度上(shang)(shang)要(yao)得益(yi)于蘋果(guo)的(de)(de)態(tai)度轉變，而(er)我們(men)并不能假設在后(hou)續所有的(de)(de)場景上(shang)(shang)蘋果(guo)都會保(bao)持這(zhe)種(zhong)開放(fang)的(de)(de)心(xin)態(tai)。同時，小(xiao)程序的(de)(de)定位更加專(zhuan)注于能力實(shi)現，在體驗和二次加載速(su)度上(shang)(shang)，相(xiang)比于H5還(huan)是有一(yi)定的(de)(de)優(you)勢(shi)。當然，相(xiang)比于定制(zhi)性和迭代速(su)度，體驗上(shang)(shang)的(de)(de)優(you)勢(shi)僅僅是一(yi)個小(xiao)細節了。

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

常青：目前(qian)iOS上的WebRTC能力還有一些不(bu)盡如人(ren)意(yi)的地方。另外，Android系(xi)統(tong)下的WebRTC實現也因為(wei)系(xi)統(tong)版本和碎(sui)片化問題(ti)有很多兼容性問題(ti)。在(zai)目前(qian)這段WebRTC還在(zai)不(bu)斷完善中(zhong)的時(shi)間(jian)里，要(yao)(yao)做到(dao)比較統(tong)一的體驗，前(qian)端工程師(shi)們(men)依然要(yao)(yao)面對(dui)很多不(bu)可控因素。

從長期來(lai)(lai)(lai)看，小程(cheng)序(xu)上的(de)(de)優(you)勢在于更好的(de)(de)可(ke)控性(xing)和可(ke)定制(zhi)性(xing)：可(ke)控性(xing)上來(lai)(lai)(lai)講，由于審核制(zhi)度的(de)(de)存(cun)在，在小程(cheng)序(xu)里出(chu)現(xian)涉黃涉政等不法現(xian)象的(de)(de)概率會(hui)接近于零(ling)；另一方面(mian)，類似美顏等更“接地氣”的(de)(de)特性(xing)的(de)(de)支持，都(dou)是WebRTC需要很長時(shi)間(jian)才能(neng)反(fan)應(ying)過來(lai)(lai)(lai)的(de)(de)，我們也非常希望(wang)后續能(neng)夠(gou)快速迭代地增加(jia)一些高性(xing)價比的(de)(de)特性(xing)進來(lai)(lai)(lai)（太過娛樂化(hua)的(de)(de)特性(xing)暫(zan)不考慮(lv)）。

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

常青：live-pusher 和(he)(he) live-player 的RTC模式本(ben)身自(zi)帶回(hui)音消(xiao)除功能，只(zhi)要(yao)設置好mode參(can)數為(wei)RTC，都是可以(yi)(yi)使用(yong)回(hui)聲消(xiao)除能力的。 而且 live-pusher 和(he)(he) live-player 沒有(you)限制第三方云(yun)服務，只(zhi)要(yao)有(you)可用(yong)的RTMP地址就可以(yi)(yi)使用(yong)，至于如(ru)何基于 live-pusher 和(he)(he) live-player 標簽實現實時通(tong)話功能，可以(yi)(yi)參(can)考(kao)：//cloud.tencent.com/doc...

LiveVideoStack：文檔中表示，小程序音視頻能力不需要指定騰訊云，但接口似乎還沒有（完全）開放？

常青：小程(cheng)序(xu)此次開(kai)放(fang)的(de)音視頻(pin)能力(li)確實不(bu)需(xu)要(yao)指定(ding)騰訊云，支持RTMP協議(yi)的(de)云商都可以對接，所有接口都已經放(fang)在了(le)文(wen)檔 //cloud.tencent.com/doc... 和//cloud.tencent.com/doc... 中(zhong)進行說明，沒有尚未暴露(lu)的(de)接口。

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

常青：如果使(shi)(shi)(shi)用(yong)(yong) live-player 標簽，可以(yi)使(shi)(shi)(shi)用(yong)(yong)RTMP協(xie)議(yi)(yi)和http-flv協(xie)議(yi)(yi)進行接入(ru)，也可以(yi)使(shi)(shi)(shi)用(yong)(yong)HLS協(xie)議(yi)(yi)接入(ru)，但HLS協(xie)議(yi)(yi)需要使(shi)(shi)(shi)用(yong)(yong)微信(xin)小程序早就開(kai)放的(de)<video>標簽。

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

常青：這里第三方(fang)的(de)相(xiang)關服務要看是云服務還是終(zhong)端服務了。如果(guo)是云服務，那(nei)是完全沒有問題的(de)，支持(chi)RTMP協(xie)議都(dou)(dou)可(ke)以（接入），比如連麥(mai)、CDN等(deng)都(dou)(dou)無(wu)限(xian)制。但如果(guo)是終(zhong)端服務，除非是JavaScript的(de)組件(jian)，否則都(dou)(dou)是不(bu)行(xing)的(de)，因(yin)為微(wei)信小程序(xu)只提(ti)供了JavaScript的(de)編程能力。美顏是我們直接將圖像處理算法打包(bao)進微(wei)信APP實現(xian)的(de)，JavaScript無(wu)法達(da)到這個計算性能的(de)要求。

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

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