責編 / 王宇豪
策劃 / LiveVideoStack
12月26日晚間，微信小程式開放了直播能力，並首先向社交、教育、醫療、政務民生、金融等五大應用場景開放。與原生App應用和基於瀏覽器的H5應用相比，小程式直播會對音視訊技術生態帶來哪些影響？微信天生的流量優勢會給開發者和運營帶來機會還是陷阱？LiveVideoStack邀請了若干位有代表性的技術人，分享各自的觀點與思考。
LiveVideoStack：對於小程式提供的這種實時音視訊功能，它是否能滿足我們一般的直播需求呢？比如它的延遲大致能達到什麼樣的水平？是否能滿足連麥等等？
劉連響：小程式的直播分為“普通直播”和“低延遲支援”。普通直播支援2-5s的延遲，低延遲的直播在400ms 之內。普通直播方案可以支援外部CDN，大規模分發沒有問題；低延遲方案最多支援10路流，並不適合連麥直播。
和君：小程式直播可以滿足大部分需求，因為直播需求主體是音視訊，其他周邊的功能也很容易實現。就之前體驗的騰訊系直播產品，延遲都能降到比較低的程度達到百毫秒級別，在這方面的積累比較豐厚。關於連麥直播還有待嘗試驗證。
高澤華：從目前有限的API資訊看， 它基本囊括了採集、編碼、推流、拉流、解碼、播放等功能，並宣稱支援實時互動。而對於一般的非互動直播，實現相對簡單，微信小程式可以滿足要求。至於連麥功能，還需要在做出來之後，通過一些測試方法分析他的能力和優點。
周思進：可以滿足一般的直播需求，我們剛做完初步測試，延遲在1-2S左右，好於一般的CDN；但對於連麥功能，延時稍微有些大，效果有些差強人意。
袁榮喜：從小程式騰訊雲提供的DEMO測試來看，它提供直播和RTC這兩塊的能力，採用的都是RTMP協議標準來實現的。直播可以進行push流和play流，直播這塊和普通直播平臺沒有什麼差別，應該可以相容大部分CDN廠商。微信小程式特意提到如果需要加速的話，可以用騰訊雲的UDP + RTMP來減少延遲，關於延遲大小官方公佈是400 ~ 800ms，基本滿足實時需求，當然具體還需要經過嚴格的測試。從目前分析來看，UDP+RTMP其實是個私有協議，因為這裡面涉及了公私鑰加密、騰訊的UDT傳輸等協議細節，換句話說，只是普通的直播可以用其他家的CDN雲，但要延遲更小、連麥等可能只能用騰訊雲了。
Peter：RTC模式是通過私有的RTMP over UDP協議保證比較低的延時的，但弱網下的低延時通話不知能否保證，建議大家實測一下，另外也沒有說明是否能夠提供回聲消除等RTC關鍵演算法特性。
張弩：目前小程式裡提供的推拉流元件主要支援RTMP協議，那麼它對延遲不敏感、單向廣播的業務支援應該是不錯的，比如秀場類業務。對於互動比較頻繁的一些業務，比如一對一教學、秀場連麥這類業務，因為TCP連結的原因，音視訊質量可能會有比較大的波動。針對這個問題，小程式也提供瞭解決辦法，配合騰訊雲服務，小程式可以使用更適合音視訊傳輸的UDP協議。另外目前還不知道小程式的伺服器端，是否能開放音視訊資料的訪問能力，如果開放的話，業務方應該可以開發出更加豐富的音視訊產品。
姜雨晴：小程式提供的實時音視訊是一種 RTC的技術解決方案。本質上和現有的WebRTC沒有太多區別，日常直播是完全可以滿足的。它的延遲水平，其實也是主要基於RTC網路構建，而不在於開放的介面本身，按照目前一些RTC網路服務提供商的質量看來，網路狀況穩定的情況下，基本可以做到400ms左右的延遲，這樣的延遲人不太容易察覺，完全可以支撐連麥等需求。而且目前連麥 PK 抓娃娃等主流低延遲音視訊網路的應用上也是基於RTC的體系在構建。可以說，這些端和網頁上可以做的低延遲網路功能都可以很好的支援。
劉雪次：微信小程式目前提供的升級實時音視訊錄製和播放能力由兩個文件來說明《實時音視訊錄製元件》和《實時音視訊播放元件》。目前看來還是以直播為主，也提供基於 RTC的點對點實時通話，尚未看到多人通話。
直播應該是以騰訊視訊云為基礎的整合，對一般直播需求而言是沒有問題的，亮眼雲也對騰訊視訊雲直播SDK的延遲效能進行過綜合評測，大約在1秒左右。而且整合到微信小程式也就解決了微信直播的問題，這也是很多使用者苦苦追求的，同時輔以社交化濾鏡、美白等功能。以目前社交化營銷分享策略，相信對一大票只做普通直播技術的技術類公司基本上是致命一擊。
至於連麥，目前從介面上沒看到多人互動視訊部分，因此還無法評說，估計暫時還是不行的。不過隨著版本的提升，應該也會很快支援。從技術上本不是太大的問題。
許建林：經過對雙人視訊通話的實際測試，兩臺手機在同一 wifi 下，延遲 700ms 左右，符合文件中 300~800ms 的說明，同城一對一時沒有準確測量，但主觀感受延遲不太明顯。這個效果對於連麥來說，大部分場景下應該都可以滿足需求了，但對於強實時互動的場景，700ms 還是比較高的，目前其他廠商諸如 Powerinfo、Agora、Zego提供的連麥服務目標延遲都是 200~500ms，延遲很敏感的場景下這個差異還是很明顯的。此外，demo 除了延遲表現不錯，回聲抑制效果也很好。
展曉凱：小程式提供的實時音視訊功能我認為還是很靠譜的，一般的直播甚至連麥的需求都可以滿足，並且連麥的延遲也是可以接受的。但短時間內比較穩定的App應該還不會遷移到小程式平臺，畢竟對於各個領域平臺而言，維護好主播與高階使用者的關係，以及提供更好的體驗（Native的體驗會比小程式好一些）是最為重要的，而如果各大廠商想快速的嘗試一個流量入口的功能，或者炒一個概念，小程式絕對是非常不錯的選擇。
LiveVideoStack：微信小程式開放了實時音視訊錄製和播放功能，是否意味著對於沒有過多開發能力或費用的中小企業或者創業公司可以花費很小的成本就能獲得直播的功能？
趙加雨：對於企業來說，要想借助音視訊相關業務獲得紅利，首先就要過技術關，畢竟高門檻和高難度開發並不是所有公司都能做到的，多數公司會選擇整合第三方公司的音視訊SDK從而在自己的應用裡快速實現音視訊的能力。
對於小程式推出實時音視訊功能，我個人認為微信小程式這次能力的開放，再次擴充套件了小程式的想象邊界，可以適用的場景非常多，比如說銀行/證券線上開戶、線上保險定損、多人會議、線上教育等等。本身就在微信的企業，可以用最新的音視訊功能，可以比較快速地實現音視訊功能，也比較依賴微信的生態，小程式開放音視訊直播功能對於以小程式為主要平臺的創業公司而言，可以方便的實現直播功能。
和君：我相信這也是小程式的初衷之一，就是讓研發能力較弱的傳統企業和中小能較快低成本的獲得網際網路入口。教育領域利好中小型和傳統教育機構，能夠以較低的成本快速的介入線上教育領域。
林正顯：確實，它讓音視訊直播的門檻又降低了很多。同時，因為小程式是嵌入到微信的，所以相關業務的推廣成本也會變得更低。我覺得它在教育、電商等領域會大有可為。另一方面，它的釋出可能對WebRTC的推廣有一定的影響。
姜雨晴：從產品開發的角度來講，小程式的LivePlayer目前提供的兩個介面，可以說非常簡便易用，產品接入主要是產品形態上的開發，開發週期不是很長。可以說是即接即用的。開發成本上並不會很高。然而直播的主要成本並不在開發方面，使用者量高的情況下，成本主要來源於網路傳輸。那麼後續的直播成本，需要看的是網路傳輸如何收費和使用。
Peter：實現直播的確更容易了，而且微信的好處是iOS安卓不用做兩套App，也便於傳播；但CDN的費用還是一樣要自己承擔的，這個才是大頭。
許建林：的確如此，官方文件有 DEMO一鍵部署教程，我跟了一下，基本無痛點（但小程式的類別不能選錯，此外如果使用開發域名，需要客戶端開啟除錯才可以訪問，雖然 Server 不太穩定，一會兒 502，一會兒不返回認證資訊，但這都是業務層的事情）。流媒體開發對技術儲備要求還是很高的，尤其是弱網場景、要求低延遲時。當然，相比於已有廠商，我覺得這只是提供了另一種選擇，但這種選擇伴隨著微信流量的優勢。
展曉凱：這是肯定的，對於初創公司或者個人開發者可以花費比較小的成本就獲得錄播、直播的功能，但是目前伺服器只能選擇走騰訊雲，其實一方面也是一種限制。
高澤華：在沒有拿到最終測試對比資料前，不好做系統的分析。從找到的內部訊息源說，這套引擎不是微信瀏覽器內建的WebRTC介面實現的。而是封裝的騰訊雲的SDK。如果是這樣，那是有機會做出一定的實時音視訊效果。
劉雪次：從開發能力上來看，理論上是這樣的，但前提是企業還是需要基本的小程式開發能力，總體上來說技術要求降低了。費用上隨著大使用者量的增長，單體成本肯定會有下降的。從這個角度來說，很多技術實力上無法跟上的CDN，IDC未來日子會相對不好過一些。值得注意的是阿里雲，金山雲這樣的企業如何應對。另外一方面，微信小程式主要還是S2B，對中小企業，甚至一些小工作室，的確是個利好。
周思進：確實，對於中小型公司而言，有了更多的選擇的機會。
袁榮喜：微信小程式支援音視訊功能對於創業公司來說是一個非常好的訊息，這意味幾行程式碼就可以完全擁有專業的音視訊系統功能，讓開發人員專注在業務開發上，大大節省了開發成本。舉個例子來說，前段時間我們幫一個朋友解決小程式裡線上抓娃娃功能，花了九牛二虎之力通過JS + MPEG1來實現，現在騰訊提供小程式這種能力，只要幾行程式碼就搞定一個低延遲的線上抓娃娃，而且穩定性比MPEG1好很多。
劉連響：直播行業發展到現在，各種CDN和SDK已經非常完備，接入成本其實已經很低。
張弩：這個功能，我覺得可能主要是應用在短視訊類產品上的。
LiveVideoStack：那對於大企業或者自身有研發能力的企業而言，小程式的這次功能開放是否會吸引布局，畢竟微信本身已經成為生活中不可或缺的工具。
林正顯：我對此事偏樂觀。一則因為它還是偏輕量級的，很多較重的開播側的功能並未整合進去；二則它也拓寬了我們業務的受眾面。以前分享到手機端是有較大問題的，尤其對iOS手機，HLS基本是唯一選擇。但HLS有延時高等種種問題，現在小程式無疑往前走了一大步。
袁榮喜：音視訊已經成為網際網路應用的一個剛需和標配功能，任何提供相關服務的雲公司和大企業是不會放過這次機會的，接下來應該有一批雲廠商會對微信小程式來做音視訊適配和支援，因為微信小程式是個巨大的流量入口。
展曉凱：是的，這是極有可能的，畢竟微信這麼大的流量入口，但如果對於國外市場就沒問題了，微信在印度以及印尼流量並不多，而今年做印度、印尼地區的公司還是可以有發展的潛力的。
張弩：基於微信的社群運營已經非常成熟。小程式也會是一個重要的流量入口，所以對於依賴流量的企業來說，小程式是一定要拿下的戰場。小程式如果能提供出更豐富的native應用，無疑會大大增加使用者粘性 。
許建林：肯定會的，尤其是文件中提到的「自建服務」，這為大企業甚至其他廠商也提供了更多可能。
Peter：微信看直播的使用者習慣還沒養成，需要觀察一下資料。
姜雨晴：確實會影響到部分企業本身對於直播技術的佈局。直播領域本身也是向著低延遲高互動性的方向上在做。也是未來直播盈利的核心點之一。微信本身的影響力會使得直播產品更貼近生活。也就是，受眾量會有所提升。這樣的情況下，對於本身直播平臺來講應該是有益處的。
周思進：大企業應該會進行佈局，作為對APP端的一個比較好的補充。
劉雪次：這個主要從業務角度來說，微信小程式支援視訊後，如這些大企業有依賴於視訊的業務，小程式能起引流作用，自然會吸引小程式佈局，這也是小程式希望看到的方面。目前微信已經社交超級入口APP，實時音視訊功能的加入，會進一步推動小程式的發展，也會吸引類似電商視訊的進一步升級，這是騰訊希望看到的視訊生態圈。
高澤華：這是微信企業化佈局的一部分，可以進一步增加微信的平臺粘性，使得微信慢慢的更接近系統。另外也會成為騰訊雲的一個企業入口，對騰訊來說是兩個部門的雙贏。
劉連響：小程式的直播只是原來直播的一個擴充, ，而且小程式的直播有非常嚴格的行業限制，並不會引起多劇烈的變化， 但會轉移一部分原生App的流量。
和君：大企業應該也會佈局，畢竟微信是很重要的流量入口，搶佔先機也很重要。就線上教育而言，微信小程式做直播對一些“情景化教學”有適用場景，可以彌補傳統老師用桌面客戶端、學生用APP或桌面端的授課模式。並且它可以和微信生態圈結合，和企業的公眾號、服務號做無縫結合，並結合已有的微信生態（如：微信支付，微信的自媒體推薦等）。
LiveVideoStack：小程式這次更新首批開放的類目有社交直播、線上教育、醫療、政務民生和金融這五類，那這種能力的開放是否也會對其他行業有著吸引？比如攝像頭監控等等。
姜雨晴：會，低延時的音視訊傳輸的應用，現在來講只是一個起始階段。除去現在已知的一些應用之外，很多其他領域，其實也會有應用場景和形態，包括像提到的攝像頭監控等。
和君：我覺得暫時不會，微信小程式的初衷是面向大眾化的、更普適、更易傳播的產品，就“攝像頭監控”而言更像是功能性的需求不太具備上述特徵，這類應用轉小程式的收益不大，這是我個人見解。如果需要充分發揮小程式的能力需要對既有的產品進行“網際網路化”的包裝和運營。
劉雪次：這是毫無疑問的。當然，騰訊是作為平臺來推視訊基礎功能，目標是提供基礎PaaS層的介面功能以及視訊雲服務，一般說來他不會通吃，而是會將應用業務層的創新留給社會第三方公司來支援。因此下一波趨勢應該是，傳統視訊業務公司如視訊監控，視訊會議的逐步轉型利用微信實時視訊功能介面推動傳統視訊業務和微信小程式對接。傳統的基於私網私有云的視訊監控，視訊會議公司必須走上轉型，當然，部分必須專網的行業除外如軍工。視訊監控的傳統紅海市場將有新的發展熱點，畢竟視訊監控+微信，這兩個體量都太大了，會產生1+1>2的效應。
劉連響：會有吸引，但目前看限制太大，攝像頭監控不在微信允許的範圍之內.。其他行業的可以等等看。
袁榮喜：個人覺得小程式音視訊在行業裡的應用還是比較欠缺的，尤其是教育和醫療。拿教育來說，不是簡單架設一個音視訊服務就可以做線上教育，線上教育終極目標是教學效果，這需要各種互動方式精妙配合才能達成，例如：無障礙書寫同步、教研體系、素材展現和互動、教學質量監控等等，可能會有部分應用開始做小程式嘗試線上教育，但效果上不會有什麼突破。小程式的這個功能還是會從娛樂直播等方面進行鋪開，畢竟娛樂接受的程度比行業應用更容易。對於未來，小程式這個功能一定會成為萬物互聯時代的一個關鍵點，不僅僅是攝像頭監控了。
高澤華：我認為完全有可能。
Peter：攝像頭有隱私問題，估計大家都敏感。
周思進：其他行業也有類似的需求，騰訊目前選擇這五類，應該是看到了這五類的龐大市場機會，其他行業其實也有很多機會，攝像頭監控也是一種“剛需”。
LiveVideoStack：在這次開放的類目中也是包含了線上教育領域，那小程式提供的直播功能對於傳統教育機構是否意味著一次機會？對於大班課、小班課和一對一課程來說，哪一種會更適合這個平臺？對於教育而言最為關鍵也是不同於其他直播的“白板”功能如何得以實現？
劉連響：小程式開放直播相信會對教育行業產生比較大的影響，尤其是一對一和小班課模式，小程式天生適合。基於小程式的白板我們已經在研發，有這個需求的可以期待一下。
冼牛：從線上教育行業特點和技術層面來看，大班課很可能是微信小程式開放實時語音視訊能力的最先受益領域；而對於小班課來說，由於RTMP-UDP只允許不超過10個使用者低延遲拉流，因此小班課人數不能超過十個人，但實際上稍大一點的小班課盈利能力會更強。此外，PPT分享和白板塗鴉等教育行業特有的能力要開發者自己去開發，並且小程式開放的能力不一定允許開發者自己開發。
張弩：目前微信在大班課場景已經應用的不錯了，對於小程式來說，在延遲性和學生舉手發言這兩個方面的使用者體驗上，一定有非常大的提升。對於線上教育上重要的白板、標註等功能來說，依賴於小程式的開發語言，應該也不是特別複雜的技術。
周思進：作為互動而言，我覺得更適合小班課和一對一。對於大班課，能夠減少延時，提高互動直播的體驗。“白板”功能目前還沒有方案。
袁榮喜：對於線上教育，可能部分應用會嘗試小程式的這個功能，最有可能的就是大班課了。為什麼呢？大班課不太在意教學效果，它關注的吸取流量，然後轉化成高價值的1對1或者小班課。小班課和1V1短時間看不到會進行小程式應用，原因還是教學效果問題。因為所有提供1對1或者小班課的應用都有自己特有的互動方式，甚至有自己的硬體支援，這不是簡單一個小程式能搞定的。
和君：對傳統教育機構這是一個難得的入局網際網路的機會，不過傳統教育機構最需要改變的還是網際網路化的思維模式，技術只是其中的小部分對一些複雜的場景（比如程式設計課教學、教學場景本身比較複雜，在移動端不能完美展現），可能還是需要傳統客戶端模式。
微信小程式內嵌自己封裝過的canvas，可以基於它做簡單的白板功能，但一些高階的白板應用（比如WebGL/AR/VR）小程式的能力還有所不足，這塊期待小程式後續版本的增強。
Peter：微信認證支付比較容易，白板技術實現不難，但在手機上不好操作，體驗可能有問題。
高澤華：我們可以把它看成是騰訊雲的一個入口。即使現在不可以，未來有可能可以。但是教育有自身特殊的屬性，對於收付費聽課的學生和老師來說體驗非常重要，從教育的角度來講，有很多細節和功能需要提供。我認為，對於未來的“微信課堂”，更多的適用模式，還是要引導到其他更加專業的線上教育平臺。
姜雨晴：除去實時音視訊介面外，小程式之前的版本中其實已經開放了類似canvas的繪圖介面。也就是說，“白板“的功能，在微信中是可實現的。通過小程式開放的websocket介面進行傳輸，繪圖介面進行繪製完全可以滿足白板功能的需求。對於普通使用者來說，不用下載單獨APP，可以快速推開受眾群。對於傳統的教育機構來說，也是對教育的高互動性增磚添瓦的。應該來說，是一次很好的機會。
然而教育的核心問題其實並不在於是APP或者是小程式，更多的是提供的教學質量。傳統學校的優秀教育資源中，有很大程度上，直播門檻限制了這些優秀老師擴充教育直播的可能性。這次小程式的上線，對於傳統教育行業，其實應該是降低直播教育的踏入門檻。對直播教育和傳統教育領域，應該都是很不錯的機會。
劉雪次：我覺得直播公開課和一對一會更適合，但這只是針對小B或者2C，對於大B教育機構企業來說，互動視訊的技術能力只是其中一個小方面，基於成本和業務這樣的考慮會更多，因此不能絕對說1對1就是適合這類平臺，得看具體物件具體分析。
對教育白板而言，用微信小程式，H5白板應該是必要途徑，但互動教育裡，以亮眼雲的亮眼課堂為例子，白板信令和視訊控制信令緊密結合，很難分開。小程式目前不提供白板，未來值得觀察。如果小程式不提供白板，這個對開發教育產品而言，確實會使一個比較頭疼的問題。這就需要各企業提供自己的結合解決方案了。最極致的，就是如亮眼課堂一樣，音視訊底層和白板都自己實現，自己整合，這樣肯定就沒問題了。
LiveVideoStack：小程式提供音視訊能力，是否會對專業音視訊服務供應商形成衝擊？
高澤華：小程式提供音視訊能力更像是騰訊雲的一個入口，大規模高質量的收費音視訊服務比較複雜，很多服務需要跨地區、跨行業、跨年齡段、跨階層等等。小程式提供音視訊能力，能衝擊到的是小的、散的、國內的開發者和小企業。而音視訊服務供應商的採購方通常是大中型廠商，有非常多的定製需求。小程式暫時還無法滿足，所以影響有限。
展曉凱：我認為短時間內還形成不了對專業音視訊服務供應商衝擊的，畢竟小程式具體到生產環境上至少還需要一段時間，並且伺服器必須走騰訊雲，如果騰訊雲的節點部署(比如國外)有瓶頸或者服務有瓶頸，那麼眾多平臺就會比較尷尬，畢竟接多個服務商然後熱切流量對於平臺來講是比較容易控制成本，產品穩定的事項，如果綁死在一家廠商上的話，可能就會被動很多。
另外有一些高階的短視訊處理，音訊處理還不成熟（對於全民K歌的音效處理，視訊處理，騰訊應該也不會開源）；另外對於短視訊社群，K歌社群，秀場直播等領域在短時間內也不會遷移到小程式中去開發新的功能；但是對於開發者是件好事情，可以讓多媒體的開發成本更低，整體開發更容易上手，可以讓一些有想法的人或者公司快速實現出一些東西，快速試錯、快速迭代。
劉連響：小程式普通直播是不繫結服務商的，但目前看低延遲的方案需要用騰訊雲的服務，會對音視訊服務供應商有一定的衝擊，但對帶動整個行業對音視訊的需求，總體上來說影響並不會很大。對於音視訊服務供應商倆說，可以做很多騰訊提供不了的服務。
許建林：這一點因「企」而異吧，如果底層技術原理基本一致，那衝擊會更大。
劉雪次：這個是毋庸置疑的，衝擊物件主要是對專業的音視訊技術服務商，衝擊程度的多少，要看騰訊的節奏。我在前面說了，對於純直播的技術服務提供商來說，可以說衝擊就在眼前，這是很殘酷的事情，擺在這些企業眼前的就是必須要進行戰略思考以面對這個衝擊。
袁榮喜：對專業的視訊服務商來說，小程式不會帶來衝擊，反而是一波巨大的機會。視訊服務商會想方設法去相容小程式的這種接入方式，把小程式的流量引入到自己的服務上，這是和蘋果Safari支援WebRTC如出一轍。
和君：會的，尤其是一些小型的，沒有自己特色的音視訊供應商 會收到較大的衝擊。騰訊在基礎設施、研發能力等方面有很大的優勢。專業音視訊供應商可能更需要在細分垂直領域深耕做出自己特色，具備不可替代性。也可以嘗試面向小程式的直播平臺，或作第三方的外包服務。
周思進：的確會形成一些衝擊，但是小程式音視訊能力的穩定性，規模性和實際效果還有待檢驗。另外，專業音視訊服務提供商的價值在於差異化和專業化，這塊還是有其本質的區別的。
姜雨晴：這點上來說應該不會造成太大問題。由於長期在泛娛樂網站工作，可以看到的是，主播都是由淺入深。最開始都是以比較好上手的APP或者平臺提供的簡單推流工具入門。後續會慢慢使用專業的開源推流工具甚至付費推流工具。更多的小程式的作用在於引入一些新的主播，降低他們的直播門檻。單對於真正有一定經驗的主播來說，由於小程式的一些限制，當他們在對其他遊戲、美顏等問題產生推流的不便性的時候，自然而然會轉化成專業音視訊服務供應商的使用者。
不僅不會造成太大沖擊，在門檻降低、主播量上升的大環境下，使用者量的擴充套件也是可預期的，對於專業音視訊服務，應該是益處大於衝擊的。對於專業音視訊服務提供商也是一個很好的給予。給個簡單的類比，京滬高鐵修通的時候，大多數人都覺得對於航空來講應該是很大的衝擊，但幾年下來，發現由於流動性加大，做飛機的人反倒多了，市場也成倍增長。小程式這次開放對於音視訊服務領域，應該會有同樣的作用。直播門檻的降低也會有更多的市場前景。
Peter：對於直播廠商來說是多了一個新的目標平臺，這個平臺依然需要直播CDN；已有安卓iOS的native平臺還需要直播推拉流SDK；無真正RTC能力，對RTC廠商影響也不大。但如果微信真的把實時音視訊通話能力通過小程式提供出來，對RTC廠商還是會有一定衝擊。
LiveVideoStack：對開發者而言，基於小程式開發多媒體相關的服務，您對他們有哪些建議？
Peter：可以嘗試一些創新的玩法，不要侷限於目前的已有產品形態，可能會有機會。
劉雪次：畢竟是多媒體應用，相關的多媒體基礎還是要的，比如一些基本概念，如取樣率、幀率、位元速率、延遲，以及直播、點播相關技術，如RTMP、HLS。如果有可能也最好從網上對一些流行的流媒體框架如FFmpeg，WebRTC多做了解，也可以動手做一些簡單的CASE。
周思進：還是建議去體驗和測試一下相關功能。
劉連響：謹慎樂觀，小程式雖然對音視訊的能力在逐漸開放，但限制還是很大， 另外加上類目的限制，需要多想想自己的業務是否很微信的要求的場景契合。
和君：小程式的特點就是“小輕”，適合“短頻快”的網際網路開發方式，快速迭代、快速試錯。可以結合騰訊雲等強大的騰訊系基礎設施，降低研發成本，畢竟小程式一定是和自己的產品結合的最完美。一些音視訊服務提供商可以考慮做出面向小程式的直播平臺。此外，小程式允許委託第三方開發和維護，這可能是一個風口，傳統的服務商可以嘗試軟體外包。
高澤華：沒有特別的建議，和普通API一樣，快開發快使用。搶佔商業先機。如果非要提的話，對開發實時音視訊服務過程中如果遇到困難，可以多討論，多分享，不要悶頭造車。
後記
由於“小程式+直播”剛剛推出，功能、效能及穩定性還未得到廣泛驗證，我們會持續關注。如果您有實踐與思考願意分享，可以直接留言或聯絡 editors@livevideostack.com 。
關於本期受訪嘉賓（以下排名不分先後）
Peter，某一線網際網路公司視訊技術團隊負責人
和君，tutorabc（原vipabc）大前端負責人
10餘年前後端研發及架構經驗，曾就職於滬江網、途牛網等網際網路公司。擅長大型前端專案架構，前端工程化，前端及Nodejs服務端效能優化等。 現負責tutorabc前端部門，以及音視訊教學平臺 "Tutormeet+" 的瀏覽器端和客戶端相關工作，致力於打造網際網路教育領域的WebRTC高效能富互動前端解決方案。
高澤華，聲網Agora.io首席音視訊架構師
11年音樂語音編解碼學習經驗，理解幾十種音訊編解碼標準。先後在中磊電子、士蘭微電子、摩托羅拉、虹軟科技主導音訊專案。先後負責晶片開發，嵌入式系統，pc軟體，移動app的音視訊子系統設計。對音視訊通訊技術的發展與應用有獨到見解。
姜雨晴，熊貓直播前端技術專家
本科畢業於四川大學，研究生畢業於加拿大Dalhousie University。曽任FedoraRepository team Member。現於熊貓直播從事H5播放器核心開發、彈幕引擎開發、WebGL開發。
林正顯，歡聚時代（YY）直播部負責人
1999~2011年，先後在3家知名通訊裝置公司擔任主任工程師、高階架構師等職。2011年加入歡聚時代（YY），T4工程師，研發總監。現分管音視訊編解碼、計算機視覺、音視訊傳輸和分發等技術團隊；在無線傳輸、IP核心網、網際網路接入、音視訊直播等領域有較豐富的經驗；多次率領團隊取得公司技術大獎，在網路及音視訊相關方向申請多項專利。
劉連響，dotEngine音視訊通話雲創始人兼CTO
全棧工程師&產品，曾就職於視覺中國、果殼網。6年產品研發經驗,四年多媒體研發經驗，獨自開發出蒙太奇短視訊社交app，蝸殼實時視訊協作平臺創始人，玩耍直播創始人
劉雪次，北京亮眼雲視科技有限公司創始人
業內頂級的視訊技術業務專家及講師。具有跨國公司技術與管理及自主多次創業的工作歷程，同時擔任多家移動網際網路公司的戰略技術顧問。北京亮眼雲視科技有限公司專注於傳統統一通訊解決方案及視訊會議產品，並於2015年轉型專攻移動網際網路的互動音視訊雲業務。
許建林
許建林（Piasy），關注安卓架構、必備開源庫原始碼導讀（拆輪子系列）、Advanced RxJava 系列部落格翻譯，目前專注於客戶端實時多媒體領域，WebRTC-Android 原始碼導讀，在 Powerinfo 從事音視訊 SDK 開發工作。
冼牛，即構科技資深技術專家、架構師
北京郵電大學計算機碩士，香港大學工商管理碩士，多年從事實時語音視訊雲服務技術研究，專注互動直播和語音視訊社交行業。
袁榮喜，學霸君資深架構師/音視訊技術負責人
核心系統工程師，16年的C程式設計師，好求甚解，善於構建高效能服務系統和系統效能調優，喜好解決系統的疑難雜症和debug技術。早年痴迷於P2P通訊網路、TCP/IP通訊協議棧和鑑權加密技術，曾基於P2P super node技術實現了視訊實時傳輸系統。2015年加入學霸君，負責構建學霸君的智慧路由實時音視訊傳輸系統和網路，解決音視訊通訊的實時性的問題。 近幾年專注於儲存系統和併發程式設計，對paxos和raft分散式協議饒有興趣。尤其喜歡資料庫核心和儲存引擎，堅持不懈對MySQL/innoDB和WiredTiger的實現和事務處理模型進行探究。熱衷於開源，曾為開源社群提過些patch。業餘時間喜歡寫技術長文，喜歡讀唐詩。
趙加雨，網易雲通訊與視訊CTO
曾深度參與 Cisco Jabber，Webex Meeting， Cisco Spark 等多項分散式實時通訊類產品的架構與研發，具備多年海外工作及大型研發團隊管理經驗，複雜實時通訊類軟體架構設計和研發經驗。
張弩，百家雲技術總監
畢業於西安電子科技大學，從06年加入北京威速科技有限公司並開始進入音視訊行業，從事企業級軟體視訊會議系統開發設計、研發工作。14年開始供職於北京百家視聯科技有限公司 ，主要負責直播產品的設計研發。涉及分散式伺服器架構、大資料傳輸、音視訊編解碼技術、多平臺客戶端支援等工作。
周思進，北京三體雲聯科技有限公司CEO
在視訊會議老大Ploycom 抗過槍，系統架構師；在軟體視訊會議行業領頭羊V2帶過隊，技術副總裁；在2家上市公司練過兵（佳訊飛鴻，九城），研發總監；目前帶領一幫兄弟自主創業（北京三體雲聯科技有限公司）CEO，立志成為國內最好的互動視訊直播雲平臺。
展曉凱，全民快樂研發高階總監
曾就職於淘寶，開發機票搜尋業務，12年加入唱吧，經歷了唱吧從上線到擁有4億使用者的整個過程，負責唱吧音視訊的開發，其中涉及到多個產品線，包括唱吧、唱吧直播間、火星等，在移動平臺音視訊採集、硬體編解碼、跨平臺的音視訊處理等方面有著豐富的經驗，目前工作於全民快樂，負責直播產品線業務，未來2個月內會有一本關於音視訊開發的書籍面市，書中詳細介紹了移動平臺下音視訊開發的整個流程，也是這些年從事移動平臺下音視訊開發的一個詳細總結，希望可以幫助到音視訊領域內更多的人們。