直播终端技术比较
目前,連麥直播的終端主要包括:原生APP、瀏覽器H5、瀏覽器WebRTC、微信小程序。瀏覽器上的應(yīng)用包括H5和WebRTC,前者可以拉流觀看,后者可以實現(xiàn)推流和拉流。
1.連麥直播移動終端-Native APP 原生APP終端音視頻引擎的結(jié)構(gòu)基本包括了音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸,合稱實時語音視頻終端引擎。這里還包含底層的音視頻采集和渲染,還有網(wǎng)絡(luò)的輸入輸出能力,這是操作系統(tǒng)開放的能力。
原生APP有個天然的好處,它是直接和操作系統(tǒng)打交道的,操作系統(tǒng)開放的資源和能力它都可以直接用,比如說音視頻的采集渲染,還有網(wǎng)絡(luò)的輸入輸出。套用一句時髦的廣告語:“沒有中間商賺差價”,直接和操作系統(tǒng)對接,可以獲得比較好的用戶體驗。在原生APP上實現(xiàn)連麥直播的優(yōu)勢是,對上面所說的七個環(huán)節(jié)有較好的把控,可以獲得比較低的延遲,能自研實現(xiàn)語音前處理3A算法,包括回聲消除,還有對抖動緩沖策略和碼率自適應(yīng)的策略都有比較好的把控。另外,可以自主選擇使用RTMP協(xié)議還是基于UDP的私有協(xié)議,對抗弱網(wǎng)環(huán)境更加有保障。
市面上比較流行的前處理技術(shù),比如美顏、掛件、變聲等,原生APP都可以通過開放前處理接口讓開發(fā)者實現(xiàn)或者對接這些技術(shù)。為什么要強調(diào)這個呢?因為瀏覽器WebRTC和微信小程序都沒有開放前處理接口,開發(fā)者沒有辦法自行實現(xiàn)或者對接第三方的美顏或者掛件等技術(shù)模塊。在原生APP上,開發(fā)者可以得到全面的把控能力,讓用戶可以獲得更好的體驗。主流的視頻直播平臺都有自己的原生APP平臺,而瀏覽器和微信小程序相對來說是輔助的。原生APP的用戶體驗是最好的,而且對開發(fā)者來說也是最可控的。
在原生APP上實現(xiàn)連麥直播的劣勢是什么呢?開發(fā)門檻高,開發(fā)周期長、人力成本高。另外,從獲取用戶和傳播的角度來講,也沒有瀏覽器和微信小程序那么便利。
2.連麥直播移動終端-瀏覽器(H5) 瀏覽器H5就像一個硬幣有兩面,有好處也有劣勢,好處是開發(fā)成本低,容易傳播,劣勢是只能拉流,不能推流,不能做到多個用戶連麥直播。另外,在瀏覽器H5上延遲也是比較大。如果使用RTMP或者HTTP-FLV,延遲會在1秒到3秒之間,如果用HLS延遲會大于8秒甚至10秒,這么大的延遲就根本就不允許實現(xiàn)連麥直播。
使用這三種協(xié)議都是通過瀏覽器H5中的播放器來播放的。在多主播連麥互動的場景中,一個播放器里面只能播一路視頻流,三個主播就得三個播放器,因此看不到多個主播同框連麥互動的情形。如果要看到多個主播同框互動的畫面,就必須把多路流混合成一路流,在單個播放器里面播放。另外,瀏覽器H5的源代碼是開放的。如果在瀏覽器上把音視頻終端引擎實現(xiàn)了,相當于對外公開了所有核心的源代碼。因此,還沒有見過哪個廠商在瀏覽器H5上完整地把音視頻引擎真正做出來。即使你愿意做出來,瀏覽器也不會允許你這樣做,開發(fā)者和操作系統(tǒng)之間隔著瀏覽器,如果瀏覽器不把操作系統(tǒng)的核心能力開放給開發(fā)者,開發(fā)者就不能自主采集和渲染,不能掌控網(wǎng)絡(luò)輸入輸出,類似流控碼控等功能無法實現(xiàn)。
在瀏覽器H5中也可以通過websocket來傳輸,用jsmpeg來播放,視頻編解碼的格式用mpeg1。mpeg1是一個比較老的媒體格式,所有瀏覽器都支持。在瀏覽器中使用jsmpeg播放器播放mpeg1,所有瀏覽器也可以支持。這么做可以獲得比較低的延遲,但是還是無法推流,沒辦法實現(xiàn)連麥直播。
3.連麥直播移動終端-瀏覽器(WebRTC) 大家可能會覺得很遺憾,瀏覽器H5雖然很容易傳播,開發(fā)簡單但是體驗欠佳,不能連麥直播。那么在瀏覽器上能不能推流,能不能實現(xiàn)連麥直播呢?答案是可以的,那就要用到WebRTC。這里說的WebRTC是指已經(jīng)被內(nèi)嵌到瀏覽器里面,被瀏覽器支持的WebRTC,而不是WebRTC的源代碼。部分主流瀏覽器內(nèi)嵌了WebRTC,對開發(fā)者開放了瀏覽器的實時音視頻能力。
WebRTC包括了音頻引擎,視頻引擎、傳輸引擎等,最底層的虛線框表示可以重載,也就是說瀏覽器把最底層的音視頻渲染和網(wǎng)絡(luò)傳輸?shù)牡讓幽芰﹂_放給開發(fā)者,開發(fā)者可以根據(jù)自己的需求選擇是否進行重載。音頻引擎中,包括了兩個編解碼器:iSAC和iLBC,前者針對寬帶和超寬帶的音頻編解碼,后者針對窄帶音頻編解碼。音頻引擎還包括了音頻抖動緩沖,回聲消除和噪音抑制模塊等。抖動緩沖中的NetEQ算法可以說是WebRTC里面的精華之一。視頻引擎中,包括了VP8和VP9的視頻編解碼器,甚至是即將到來的AV1。視頻引擎還包括視頻抖動緩沖和圖像質(zhì)量增強等模塊。傳輸引擎,WebRTC使用的是SRTP(Secured Realtime Transport Protocol)安全實時傳輸協(xié)議。
最后,WebRTC采取P2P的通信方式,沒有媒體服務(wù)器等后端的實現(xiàn)。以上是WebRTC的簡單介紹。瀏覽器WebRTC一般的優(yōu)勢和劣勢這里就不再重復(fù),請大家自行百度,這里只說重點。瀏覽器WebRTC的好處就是實現(xiàn)了相對完整的音視頻終端引擎,允許在瀏覽器上推流,可以實現(xiàn)連麥直播。然而,瀏覽器WebRTC也有不足: 1)沒有開放前處理接口,美顏和掛件這些模塊沒辦法接入第三方的或者自研方案。 2)媒體服務(wù)器后端沒有實現(xiàn),開發(fā)者要實現(xiàn)媒體服務(wù)器,然后通過開源WebRTC網(wǎng)關(guān)(比如說janus)接入。 3)編解碼器、抖動緩沖和語音前處理3A等能力只能依靠WebRTC,不能自行定制化。 4)部分主流瀏覽器是不支持WebRTC的,特別是蘋果的瀏覽器。雖然說去年蘋果宣布支持WebRTC,但是目前iOS Safari最新版本對WebRTC的支持并不好,iOS Safari的主流版本并不支持WebRTC,在iOS上面微信瀏覽器也是不支持WebRTC的。 5)由于WebRTC不提供媒體服務(wù)器的實現(xiàn),因此需要把瀏覽器WebRTC接入到媒體服務(wù)器后端,這個可以是自研的,也可以是第三方的服務(wù)。瀏覽器WebRTC和媒體服務(wù)器后端之間的協(xié)議和媒體格式是不一樣的,因此要做協(xié)議和格式的轉(zhuǎn)換。WebRTC用的基于UDP的SRTP,需要把它轉(zhuǎn)換成媒體服務(wù)器的基于UDP的私有協(xié)議。另外,媒體格式也需要轉(zhuǎn)換,因為WebRTC中語音視頻格式默認用的是VP8或者VP9。同時實時傳輸網(wǎng)絡(luò)中有關(guān)信令調(diào)度也需要做一些調(diào)整。瀏覽器WebRTC和媒體服務(wù)器后端之間的接入層也可以采用開源的WebRTC Gateway(比如說janus)來實現(xiàn)。
瀏覽器是類似操作系統(tǒng)的一種超級應(yīng)用,它坐擁重要的流量入口,然而它也是開發(fā)者和操作系統(tǒng)之間的“中間商”。開發(fā)者通過WebRTC獲得瀏覽器開放的實時音視頻能力,然而也必須要承受WebRTC帶來的痛苦。
4.連麥直播移動終端-微信小程序 微信小程序是什么?是跑在微信上面的輕型應(yīng)用。微信是什么?是類操作系統(tǒng)的超級應(yīng)用。這些特征和瀏覽器以及H5是不是很接近?H5是瀏覽器支持的輕型應(yīng)用,而瀏覽器是類操作系統(tǒng)的超級應(yīng)用。瀏覽器背后是各大國際科技巨頭,不像微信這樣背后只有騰訊一個互聯(lián)網(wǎng)巨頭。因此,從這個角度來看,微信小程序、瀏覽器WebRTC和H5是有相通之處的。
微信小程序可以類比為瀏覽器H5那樣的客戶端和服務(wù)器的結(jié)構(gòu)。其中HTML對應(yīng)微信小程序的WXML,CSS對應(yīng)小程序的WXSS,小程序的腳本語言和JS是一樣的,只是框架不一樣。微信小程序提供了兩個標簽,一個是<live-pusher>,一個是<live-player>。<live-pusher>就是推流,<live-player>就是拉流,可以實現(xiàn)單向直播或者連麥直播。小程序提供兩種模式:LIVE和RTC,LIVE支持單向直播,RTC支持低延遲的連麥直播。目前微信小程序推流采用RTMP協(xié)議,如果要和私有協(xié)議互通,需要進行協(xié)議轉(zhuǎn)換。
微信小程序開放了實時音視頻能力,對業(yè)界來說是重大利好。然而,根據(jù)上面的信息和邏輯,我們也看到采用微信小程序?qū)崿F(xiàn)連麥互動直播的好處和不足。好處有三點: 1)開發(fā)成本低,開發(fā)周期短,基本和H5的開發(fā)難度差不多; 2)很容易傳播和獲客,充分利用好微信的優(yōu)質(zhì)流量; 3)可以推流和拉流,允許實現(xiàn)連麥直播和實時語音視頻通話。 另外,不足有四點: 1)你會受制于微信小程序的實時音視頻能力,比如說,如果它的回聲消除有某些問題,你只能等微信團隊按照自己的節(jié)奏來優(yōu)化,而自己沒有任何辦法去優(yōu)化。 2)小程序沒有開放前處理接口,只能使用小程序自帶的美顏或者變聲功能(如果有),不能對接自行研發(fā)或者第三方的美顏或者變聲模塊。 3)通過RTMP協(xié)議推流和拉流,不能和基于UDP的私有協(xié)議互通連麥。如果要實現(xiàn)和基于UDP的私有協(xié)議互通連麥,就必須要增加接入層來轉(zhuǎn)換協(xié)議格式甚至媒體格式。 4)沒有實現(xiàn)后端媒體服務(wù)器,開發(fā)者必須要自行實現(xiàn)媒體服務(wù)器,或者把微信小程序接入到第三方的實時通信網(wǎng)絡(luò)。
瀏覽器通過WebRTC開放了瀏覽器的實時音視頻能力,而微信通過小程序開放了微信的實時音視頻能力,在兩個類操作系統(tǒng)的平臺上允許開發(fā)者去實現(xiàn)連麥直播和實時音視頻通話。然而,無論WebRTC還是小程序只是在終端上帶你入門,對開發(fā)者來說,要真正實現(xiàn)整套系統(tǒng),還有很多工作需要做的。如果要將微信小程序接入實時音視頻傳輸網(wǎng)絡(luò),中間得有接入服務(wù)器,我們叫接入層。在接入層我們需要做協(xié)議的轉(zhuǎn)換,比如說,如果實時音視頻傳輸網(wǎng)絡(luò)是使用基于UDP的私有協(xié)議,那么要把RTMP協(xié)議轉(zhuǎn)為基于UDP的私有協(xié)議。還有媒體格式的轉(zhuǎn)換,如果和實時傳輸網(wǎng)絡(luò)的媒體格式不一樣,還需要進行轉(zhuǎn)換。
5.連麥直播移動終端-WebRTC通過WebView接入小程序 還有別的方法在小程序上做連麥直播互動嗎?必須要使用微信小程序開放的語音視頻能力嗎?也不一定。下圖展示了我在市面上看過的一個技術(shù)方案,它繞過了微信小程序?qū)崟r語音視頻能力,通過微信小程序WebView組件實現(xiàn)了連麥直播的方案。這里和大家分享一下。
這個方案的基本思路是利用WebView的瀏覽器特點,在WebView內(nèi)使用WebRTC的Web API,從而在小程序上獲得實時音視頻能力。最底層是微信小程序的基礎(chǔ)能力。上一層是WebView,微信小程序的WebView類似瀏覽器,那么就可能會支持WebRTC。然而必須要注意到,微信小程序的WebView在安卓平臺上支持WebRTC,但在iOS平臺上面不支持WebRTC。雖然這個方案理論上也能在微信小程序上實現(xiàn)連麥直播,但是它有以下的局限性: 1)在iOS平臺上,微信小程序不支持這個方案,上面已經(jīng)說過。 2)小程序WebView不是完整的瀏覽器,要比普通瀏覽器表現(xiàn)差而且有很多的限制。 3)開發(fā)者和操作系統(tǒng)之間隔了好幾層:微信底層,小程序,WebView,WebRTC,然后才是開發(fā)者的小程序應(yīng)用。每一層的抽象都會帶來性能上的消耗,都會影響到最終的體驗。 這個方案本質(zhì)上還是一個基于WebRTC的解決方案,沒有用到微信小程序開放的實時音視頻能力,而是快速地借助WebView組件,劍走偏鋒,十分討巧地在微信小程序里使用了WebRTC。
連麥直播技術(shù)逐步在原生APP, 瀏覽器H5,瀏覽器WebRTC,微信小程序上延伸,衍生出更加豐富的生態(tài),提供更加便捷和良好的用戶體驗,對視頻直播平臺和用戶來說是好消息。然而,欲帶皇冠,必承其重。特別是在瀏覽器WebRTC和微信小程序上,開發(fā)者要充分理解這些類型終端的特點和局限,才能更好地在上面利用連麥直播技術(shù)進行創(chuàng)新,服務(wù)用戶。
引用:冼牛的《直播終端技術(shù)比較:Native vs H5 vs WebRTC vs 小程序》 超強干貨來襲 云風專訪:近40年碼齡,通宵達旦的技術(shù)人生
1.連麥直播移動終端-Native APP 原生APP終端音視頻引擎的結(jié)構(gòu)基本包括了音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸,合稱實時語音視頻終端引擎。這里還包含底層的音視頻采集和渲染,還有網(wǎng)絡(luò)的輸入輸出能力,這是操作系統(tǒng)開放的能力。
原生APP有個天然的好處,它是直接和操作系統(tǒng)打交道的,操作系統(tǒng)開放的資源和能力它都可以直接用,比如說音視頻的采集渲染,還有網(wǎng)絡(luò)的輸入輸出。套用一句時髦的廣告語:“沒有中間商賺差價”,直接和操作系統(tǒng)對接,可以獲得比較好的用戶體驗。在原生APP上實現(xiàn)連麥直播的優(yōu)勢是,對上面所說的七個環(huán)節(jié)有較好的把控,可以獲得比較低的延遲,能自研實現(xiàn)語音前處理3A算法,包括回聲消除,還有對抖動緩沖策略和碼率自適應(yīng)的策略都有比較好的把控。另外,可以自主選擇使用RTMP協(xié)議還是基于UDP的私有協(xié)議,對抗弱網(wǎng)環(huán)境更加有保障。
市面上比較流行的前處理技術(shù),比如美顏、掛件、變聲等,原生APP都可以通過開放前處理接口讓開發(fā)者實現(xiàn)或者對接這些技術(shù)。為什么要強調(diào)這個呢?因為瀏覽器WebRTC和微信小程序都沒有開放前處理接口,開發(fā)者沒有辦法自行實現(xiàn)或者對接第三方的美顏或者掛件等技術(shù)模塊。在原生APP上,開發(fā)者可以得到全面的把控能力,讓用戶可以獲得更好的體驗。主流的視頻直播平臺都有自己的原生APP平臺,而瀏覽器和微信小程序相對來說是輔助的。原生APP的用戶體驗是最好的,而且對開發(fā)者來說也是最可控的。
在原生APP上實現(xiàn)連麥直播的劣勢是什么呢?開發(fā)門檻高,開發(fā)周期長、人力成本高。另外,從獲取用戶和傳播的角度來講,也沒有瀏覽器和微信小程序那么便利。
2.連麥直播移動終端-瀏覽器(H5) 瀏覽器H5就像一個硬幣有兩面,有好處也有劣勢,好處是開發(fā)成本低,容易傳播,劣勢是只能拉流,不能推流,不能做到多個用戶連麥直播。另外,在瀏覽器H5上延遲也是比較大。如果使用RTMP或者HTTP-FLV,延遲會在1秒到3秒之間,如果用HLS延遲會大于8秒甚至10秒,這么大的延遲就根本就不允許實現(xiàn)連麥直播。
使用這三種協(xié)議都是通過瀏覽器H5中的播放器來播放的。在多主播連麥互動的場景中,一個播放器里面只能播一路視頻流,三個主播就得三個播放器,因此看不到多個主播同框連麥互動的情形。如果要看到多個主播同框互動的畫面,就必須把多路流混合成一路流,在單個播放器里面播放。另外,瀏覽器H5的源代碼是開放的。如果在瀏覽器上把音視頻終端引擎實現(xiàn)了,相當于對外公開了所有核心的源代碼。因此,還沒有見過哪個廠商在瀏覽器H5上完整地把音視頻引擎真正做出來。即使你愿意做出來,瀏覽器也不會允許你這樣做,開發(fā)者和操作系統(tǒng)之間隔著瀏覽器,如果瀏覽器不把操作系統(tǒng)的核心能力開放給開發(fā)者,開發(fā)者就不能自主采集和渲染,不能掌控網(wǎng)絡(luò)輸入輸出,類似流控碼控等功能無法實現(xiàn)。
在瀏覽器H5中也可以通過websocket來傳輸,用jsmpeg來播放,視頻編解碼的格式用mpeg1。mpeg1是一個比較老的媒體格式,所有瀏覽器都支持。在瀏覽器中使用jsmpeg播放器播放mpeg1,所有瀏覽器也可以支持。這么做可以獲得比較低的延遲,但是還是無法推流,沒辦法實現(xiàn)連麥直播。
3.連麥直播移動終端-瀏覽器(WebRTC) 大家可能會覺得很遺憾,瀏覽器H5雖然很容易傳播,開發(fā)簡單但是體驗欠佳,不能連麥直播。那么在瀏覽器上能不能推流,能不能實現(xiàn)連麥直播呢?答案是可以的,那就要用到WebRTC。這里說的WebRTC是指已經(jīng)被內(nèi)嵌到瀏覽器里面,被瀏覽器支持的WebRTC,而不是WebRTC的源代碼。部分主流瀏覽器內(nèi)嵌了WebRTC,對開發(fā)者開放了瀏覽器的實時音視頻能力。
WebRTC包括了音頻引擎,視頻引擎、傳輸引擎等,最底層的虛線框表示可以重載,也就是說瀏覽器把最底層的音視頻渲染和網(wǎng)絡(luò)傳輸?shù)牡讓幽芰﹂_放給開發(fā)者,開發(fā)者可以根據(jù)自己的需求選擇是否進行重載。音頻引擎中,包括了兩個編解碼器:iSAC和iLBC,前者針對寬帶和超寬帶的音頻編解碼,后者針對窄帶音頻編解碼。音頻引擎還包括了音頻抖動緩沖,回聲消除和噪音抑制模塊等。抖動緩沖中的NetEQ算法可以說是WebRTC里面的精華之一。視頻引擎中,包括了VP8和VP9的視頻編解碼器,甚至是即將到來的AV1。視頻引擎還包括視頻抖動緩沖和圖像質(zhì)量增強等模塊。傳輸引擎,WebRTC使用的是SRTP(Secured Realtime Transport Protocol)安全實時傳輸協(xié)議。
最后,WebRTC采取P2P的通信方式,沒有媒體服務(wù)器等后端的實現(xiàn)。以上是WebRTC的簡單介紹。瀏覽器WebRTC一般的優(yōu)勢和劣勢這里就不再重復(fù),請大家自行百度,這里只說重點。瀏覽器WebRTC的好處就是實現(xiàn)了相對完整的音視頻終端引擎,允許在瀏覽器上推流,可以實現(xiàn)連麥直播。然而,瀏覽器WebRTC也有不足: 1)沒有開放前處理接口,美顏和掛件這些模塊沒辦法接入第三方的或者自研方案。 2)媒體服務(wù)器后端沒有實現(xiàn),開發(fā)者要實現(xiàn)媒體服務(wù)器,然后通過開源WebRTC網(wǎng)關(guān)(比如說janus)接入。 3)編解碼器、抖動緩沖和語音前處理3A等能力只能依靠WebRTC,不能自行定制化。 4)部分主流瀏覽器是不支持WebRTC的,特別是蘋果的瀏覽器。雖然說去年蘋果宣布支持WebRTC,但是目前iOS Safari最新版本對WebRTC的支持并不好,iOS Safari的主流版本并不支持WebRTC,在iOS上面微信瀏覽器也是不支持WebRTC的。 5)由于WebRTC不提供媒體服務(wù)器的實現(xiàn),因此需要把瀏覽器WebRTC接入到媒體服務(wù)器后端,這個可以是自研的,也可以是第三方的服務(wù)。瀏覽器WebRTC和媒體服務(wù)器后端之間的協(xié)議和媒體格式是不一樣的,因此要做協(xié)議和格式的轉(zhuǎn)換。WebRTC用的基于UDP的SRTP,需要把它轉(zhuǎn)換成媒體服務(wù)器的基于UDP的私有協(xié)議。另外,媒體格式也需要轉(zhuǎn)換,因為WebRTC中語音視頻格式默認用的是VP8或者VP9。同時實時傳輸網(wǎng)絡(luò)中有關(guān)信令調(diào)度也需要做一些調(diào)整。瀏覽器WebRTC和媒體服務(wù)器后端之間的接入層也可以采用開源的WebRTC Gateway(比如說janus)來實現(xiàn)。
瀏覽器是類似操作系統(tǒng)的一種超級應(yīng)用,它坐擁重要的流量入口,然而它也是開發(fā)者和操作系統(tǒng)之間的“中間商”。開發(fā)者通過WebRTC獲得瀏覽器開放的實時音視頻能力,然而也必須要承受WebRTC帶來的痛苦。
4.連麥直播移動終端-微信小程序 微信小程序是什么?是跑在微信上面的輕型應(yīng)用。微信是什么?是類操作系統(tǒng)的超級應(yīng)用。這些特征和瀏覽器以及H5是不是很接近?H5是瀏覽器支持的輕型應(yīng)用,而瀏覽器是類操作系統(tǒng)的超級應(yīng)用。瀏覽器背后是各大國際科技巨頭,不像微信這樣背后只有騰訊一個互聯(lián)網(wǎng)巨頭。因此,從這個角度來看,微信小程序、瀏覽器WebRTC和H5是有相通之處的。
微信小程序可以類比為瀏覽器H5那樣的客戶端和服務(wù)器的結(jié)構(gòu)。其中HTML對應(yīng)微信小程序的WXML,CSS對應(yīng)小程序的WXSS,小程序的腳本語言和JS是一樣的,只是框架不一樣。微信小程序提供了兩個標簽,一個是<live-pusher>,一個是<live-player>。<live-pusher>就是推流,<live-player>就是拉流,可以實現(xiàn)單向直播或者連麥直播。小程序提供兩種模式:LIVE和RTC,LIVE支持單向直播,RTC支持低延遲的連麥直播。目前微信小程序推流采用RTMP協(xié)議,如果要和私有協(xié)議互通,需要進行協(xié)議轉(zhuǎn)換。
微信小程序開放了實時音視頻能力,對業(yè)界來說是重大利好。然而,根據(jù)上面的信息和邏輯,我們也看到采用微信小程序?qū)崿F(xiàn)連麥互動直播的好處和不足。好處有三點: 1)開發(fā)成本低,開發(fā)周期短,基本和H5的開發(fā)難度差不多; 2)很容易傳播和獲客,充分利用好微信的優(yōu)質(zhì)流量; 3)可以推流和拉流,允許實現(xiàn)連麥直播和實時語音視頻通話。 另外,不足有四點: 1)你會受制于微信小程序的實時音視頻能力,比如說,如果它的回聲消除有某些問題,你只能等微信團隊按照自己的節(jié)奏來優(yōu)化,而自己沒有任何辦法去優(yōu)化。 2)小程序沒有開放前處理接口,只能使用小程序自帶的美顏或者變聲功能(如果有),不能對接自行研發(fā)或者第三方的美顏或者變聲模塊。 3)通過RTMP協(xié)議推流和拉流,不能和基于UDP的私有協(xié)議互通連麥。如果要實現(xiàn)和基于UDP的私有協(xié)議互通連麥,就必須要增加接入層來轉(zhuǎn)換協(xié)議格式甚至媒體格式。 4)沒有實現(xiàn)后端媒體服務(wù)器,開發(fā)者必須要自行實現(xiàn)媒體服務(wù)器,或者把微信小程序接入到第三方的實時通信網(wǎng)絡(luò)。
瀏覽器通過WebRTC開放了瀏覽器的實時音視頻能力,而微信通過小程序開放了微信的實時音視頻能力,在兩個類操作系統(tǒng)的平臺上允許開發(fā)者去實現(xiàn)連麥直播和實時音視頻通話。然而,無論WebRTC還是小程序只是在終端上帶你入門,對開發(fā)者來說,要真正實現(xiàn)整套系統(tǒng),還有很多工作需要做的。如果要將微信小程序接入實時音視頻傳輸網(wǎng)絡(luò),中間得有接入服務(wù)器,我們叫接入層。在接入層我們需要做協(xié)議的轉(zhuǎn)換,比如說,如果實時音視頻傳輸網(wǎng)絡(luò)是使用基于UDP的私有協(xié)議,那么要把RTMP協(xié)議轉(zhuǎn)為基于UDP的私有協(xié)議。還有媒體格式的轉(zhuǎn)換,如果和實時傳輸網(wǎng)絡(luò)的媒體格式不一樣,還需要進行轉(zhuǎn)換。
5.連麥直播移動終端-WebRTC通過WebView接入小程序 還有別的方法在小程序上做連麥直播互動嗎?必須要使用微信小程序開放的語音視頻能力嗎?也不一定。下圖展示了我在市面上看過的一個技術(shù)方案,它繞過了微信小程序?qū)崟r語音視頻能力,通過微信小程序WebView組件實現(xiàn)了連麥直播的方案。這里和大家分享一下。
這個方案的基本思路是利用WebView的瀏覽器特點,在WebView內(nèi)使用WebRTC的Web API,從而在小程序上獲得實時音視頻能力。最底層是微信小程序的基礎(chǔ)能力。上一層是WebView,微信小程序的WebView類似瀏覽器,那么就可能會支持WebRTC。然而必須要注意到,微信小程序的WebView在安卓平臺上支持WebRTC,但在iOS平臺上面不支持WebRTC。雖然這個方案理論上也能在微信小程序上實現(xiàn)連麥直播,但是它有以下的局限性: 1)在iOS平臺上,微信小程序不支持這個方案,上面已經(jīng)說過。 2)小程序WebView不是完整的瀏覽器,要比普通瀏覽器表現(xiàn)差而且有很多的限制。 3)開發(fā)者和操作系統(tǒng)之間隔了好幾層:微信底層,小程序,WebView,WebRTC,然后才是開發(fā)者的小程序應(yīng)用。每一層的抽象都會帶來性能上的消耗,都會影響到最終的體驗。 這個方案本質(zhì)上還是一個基于WebRTC的解決方案,沒有用到微信小程序開放的實時音視頻能力,而是快速地借助WebView組件,劍走偏鋒,十分討巧地在微信小程序里使用了WebRTC。
連麥直播技術(shù)逐步在原生APP, 瀏覽器H5,瀏覽器WebRTC,微信小程序上延伸,衍生出更加豐富的生態(tài),提供更加便捷和良好的用戶體驗,對視頻直播平臺和用戶來說是好消息。然而,欲帶皇冠,必承其重。特別是在瀏覽器WebRTC和微信小程序上,開發(fā)者要充分理解這些類型終端的特點和局限,才能更好地在上面利用連麥直播技術(shù)進行創(chuàng)新,服務(wù)用戶。
引用:冼牛的《直播終端技術(shù)比較:Native vs H5 vs WebRTC vs 小程序》 超強干貨來襲 云風專訪:近40年碼齡,通宵達旦的技術(shù)人生
總結(jié)
- 上一篇: WebRTC各种资料集合(WebRtc入
- 下一篇: 直播技术原理讲解