<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 手機(jī)與無線通信 > 設(shè)計(jì)應(yīng)用 > 建一個(gè)完整的移動(dòng)直播系統(tǒng)至少要做到這幾點(diǎn)

          建一個(gè)完整的移動(dòng)直播系統(tǒng)至少要做到這幾點(diǎn)

          作者: 時(shí)間:2017-10-22 來源:網(wǎng)絡(luò) 收藏

          注:本文作者蔣海兵,趣拍產(chǎn)品總監(jiān),直播行業(yè)老兵。

          本文引用地址:http://www.ex-cimer.com/article/201710/367676.htm

            移動(dòng)直播行業(yè)的火熱會(huì)在很長一段時(shí)間內(nèi)持續(xù),通過和各行業(yè)的整合,從而成為具有無限可能性的行業(yè)。主要有以下三個(gè)原因:

            第一,移動(dòng)直播的UGC生產(chǎn)模式比PC端的直播更明顯,人人都有設(shè)備,隨時(shí)隨地開播,完全順應(yīng)了互聯(lián)網(wǎng)時(shí)代的開放性原則,能刺激更多人去創(chuàng)造和傳播優(yōu)質(zhì)內(nèi)容。

            第二,網(wǎng)絡(luò)帶寬和速度在逐漸提高,網(wǎng)絡(luò)成本在逐漸下降,為移動(dòng)直播提供一個(gè)極佳的發(fā)展環(huán)境。文字、聲音、視頻、游戲等都會(huì)在移動(dòng)直播中呈現(xiàn),創(chuàng)造出更加豐富的用戶體驗(yàn)。直播可以以SDK的形式接入到自己的應(yīng)用中,比如,教育領(lǐng)域中的課后輔導(dǎo)完全可以以直播的形式開展業(yè)務(wù)、電商也可借助直播讓用戶挑選商品,促進(jìn)銷售。

            第三,一個(gè)與VR/AR技術(shù)相結(jié)合的移動(dòng)直播為整個(gè)行業(yè)的未來提供了新的發(fā)展空間。VR/AR直播能夠讓用戶身臨其境,帶動(dòng)主播與觀眾更貼近真實(shí)的互動(dòng),大大提高平臺(tái)的用戶參與度。

            當(dāng)下,有技術(shù)實(shí)力和流量優(yōu)勢的互聯(lián)網(wǎng)從業(yè)者都不愿錯(cuò)過直播這個(gè)風(fēng)口,如何快速搭建一個(gè)直播系統(tǒng)成了大家關(guān)心的問題,我想和大家分享下我的經(jīng)驗(yàn)。我從事于一家直播產(chǎn)品開發(fā)商,我們的產(chǎn)品為了快速趕上市場,使用了云服務(wù)提供商的直播SDK。

            從業(yè)者都知道,一個(gè)完整直播產(chǎn)品應(yīng)該包含以下環(huán)節(jié):推流端(采集、前處理、編碼、推流)、服務(wù)端處理(轉(zhuǎn)碼、錄制、截圖、鑒黃)、播放器(拉流、解碼、渲染)、互動(dòng)系統(tǒng)(聊天室、禮物系統(tǒng)、贊)。 下面我就一一講述下直播SDK在各個(gè)環(huán)節(jié)所做的工作。

            一、移動(dòng)直播推流端需要做哪些工作?

            直播推流端即主播端,主要通過手機(jī)攝像頭采集視頻數(shù)據(jù)和麥克風(fēng)采集音頻數(shù)據(jù),經(jīng)過一系列前處理、編碼、封裝,然后推流到CDN進(jìn)行分發(fā)。

            

            1、采集

            移動(dòng)直播SDK通過手機(jī)攝像頭和麥克風(fēng)直接采集音視頻數(shù)據(jù)。其中,視頻采樣數(shù)據(jù)一般采用RGB或YUV格式、音頻采樣數(shù)據(jù)一般采用PCM格式。采集到的原始音視頻的體積是非常大的,需要經(jīng)過壓縮技術(shù)處理來提高傳輸效率。
          附:(采集,iOS是比較簡單的,Android則要做些機(jī)型適配工作,PC最麻煩各種奇葩攝像頭驅(qū)動(dòng),出了問題特別不好處理,建議放棄PC只支持手機(jī)主播,目前幾個(gè)新進(jìn)的直播平臺(tái)都是這樣的。)

            2、前處理

            在這個(gè)環(huán)節(jié)主要處理美顏、水印、模糊等效果。美顏功能幾乎是直播的標(biāo)配功能(80%的主播不美顏壓根沒法看)。我們調(diào)研中發(fā)現(xiàn)太多case是因?yàn)闆]有美顏功能被拋棄使用的。另外國家明確提出了,所有直播都必須打有水印并回放留存15天以上。

            3、編碼

            為了便于手機(jī)視頻的推流、拉流以及存儲(chǔ),通常采用視頻編碼壓縮技術(shù)來減少視頻的體積,現(xiàn)在比較常用的視頻編碼是H.264。在音頻方面,比較常用的是AAC 編碼格式,其它如MP3、WMA也是可選方案。視頻經(jīng)過編碼壓縮大大提高了視頻的存儲(chǔ)和傳輸效率,當(dāng)然,經(jīng)過壓縮后的視頻在播放時(shí)必須進(jìn)行解碼。
          附:(編碼,肯定要采用硬編碼,軟編碼720p完全沒希望,勉強(qiáng)能編碼也會(huì)導(dǎo)致CPU過熱燙到攝像頭。硬編碼兼容性又是一個(gè)大坑,android上要有人去填。編碼要在分辨率,幀率,碼率,等參數(shù)設(shè)計(jì)上找到最佳平衡點(diǎn)。)

            4、推流

            要想用于推流還必須把音視頻數(shù)據(jù)使用傳輸協(xié)議進(jìn)行封裝,變成流數(shù)據(jù)。常用的流傳輸協(xié)議有RTSP、RTMP、HLS等,使用RTMP傳輸?shù)难訒r(shí)通常在1–3秒,對(duì)于移動(dòng)直播這種實(shí)時(shí)性要求非常高的場景,RTMP也成為移動(dòng)直播中最常用的流傳輸協(xié)議。最后通過一定的Qos算法將音視頻流數(shù)據(jù)推送到網(wǎng)絡(luò)斷,通過CDN進(jìn)行分發(fā)。在直播場景中,網(wǎng)絡(luò)不穩(wěn)定是非常常見的,這時(shí)就需要 Qos來保證網(wǎng)絡(luò)不穩(wěn)情況下的用戶觀看直播的體驗(yàn),通常是通過主播端和播放端設(shè)置緩存,讓碼率均勻。另外,針對(duì)實(shí)時(shí)變化的網(wǎng)絡(luò)狀況,動(dòng)態(tài)碼率和幀率也是最常用的策略。
          附:(推流,自己做不現(xiàn)實(shí),交給CDN服務(wù)商吧,也就是貴了點(diǎn),相信有志于做直播平臺(tái)改變世界的你不差錢。假設(shè)2W PCU大約每月帶寬費(fèi)用100萬左右,因?yàn)榍逦鲿车?20p要1.5mbps左右。CDN只提供了帶寬和服務(wù)器間傳輸,發(fā)送和接收端的網(wǎng)絡(luò)連接抖動(dòng)緩沖還是要自己寫的。不想要卡頓,必然要加大緩沖,會(huì)導(dǎo)致延遲高,延遲高影響互動(dòng)性,要做權(quán)衡。)

            二、服務(wù)端處理需要做哪些工作?

            要想適配各終端和平臺(tái),服務(wù)端還需要對(duì)推流進(jìn)行轉(zhuǎn)碼,如支持RTMP、HLS、FLV等格式拉流,支持一路轉(zhuǎn)多路適配不同網(wǎng)絡(luò)和分辨率的終端設(shè)備。

            1、截圖、錄制、水印

            2、鑒黃

            第一種是對(duì)視頻進(jìn)行截圖,然后對(duì)圖片進(jìn)行鑒黃,返回鑒黃結(jié)果和分值。典型的企業(yè)有阿里(綠網(wǎng))、圖譜科技,他們目前都支持直接傳入視頻,經(jīng)過服務(wù)端分析返回結(jié)果。通常由業(yè)務(wù)系統(tǒng)接入鑒黃服務(wù),根據(jù)鑒黃結(jié)果對(duì)直播流進(jìn)行控制,如切斷直播流、封禁賬號(hào)等。

            第二種是和CDN結(jié)合,直接對(duì)直播流進(jìn)行分析,識(shí)別結(jié)果分為色情、疑似色情、性感和正常,業(yè)務(wù)系統(tǒng)根據(jù)識(shí)別結(jié)果直接控制直播流。典型的企業(yè)是Viscovery,這套方案的優(yōu)點(diǎn)是實(shí)時(shí)性保證比較好,缺點(diǎn)是必須部署到CDN或自己的機(jī)房,使用成本相對(duì)高一些。

            三、播放器端需要做哪些工作?

            在播放器端如何做到秒開,直播過程中保證畫面和聲音清晰度的同時(shí),穩(wěn)定、流程、無卡頓的直播流量,這些工作都需要播放器端配合服務(wù)端來做優(yōu)化,做到精確調(diào)度。

            1、拉流

            拉流實(shí)際是推流的逆過程。首先通過播放端獲取碼流,標(biāo)準(zhǔn)的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專利協(xié)議,開源軟件和開源庫都支持的比較好,如開源的librtmp庫,播放端只要支持flashPlayer的就能非常簡單的播放RTMP直播,直播延遲一般在1–3秒。

            各拉流協(xié)議的差異:

            

            2、解碼和渲染

            拉流獲取封裝的視頻數(shù)據(jù)后,必須通過解碼器解碼、渲染后才能在播放器上播放。它是編碼的逆過程,是指從音視頻的數(shù)據(jù)中提取原始數(shù)據(jù)。前面介紹的H.264和 H.265編碼格式都是有損壓縮,所以在提取后的原始數(shù)據(jù),并非原始采樣數(shù)據(jù),存在一定的信息丟失。因此,在視頻體積最小的情況下通過各種編碼參數(shù)保留最好的原始畫面,成為了各視頻公司的核心機(jī)密。

            考慮對(duì)高清的支持,解碼肯定還是要選擇硬解碼的。前面介紹過,iOS系統(tǒng)由于硬件比較單一、比較封閉,支持的比較好,Android系統(tǒng)由于平臺(tái)差異非常大,編解碼要完全兼容各平臺(tái)還需要很多工作要做。

            四、移動(dòng)直播中的交互系統(tǒng)

            移動(dòng)直播中最常見的交互有聊天室(彈幕)、點(diǎn)贊、打賞和禮物等,交互系統(tǒng)涉及消息的實(shí)時(shí)性和互動(dòng)性,在技術(shù)實(shí)現(xiàn)上大多是使用IM的功能來實(shí)現(xiàn)的。對(duì)于在線人數(shù)比較多的房間,彈幕消息量是非常大,主播與用戶其實(shí)都看不過來,為了緩解服務(wù)器壓力,在產(chǎn)品策略需要做一些必要的優(yōu)化。

            1、聊天室

            移動(dòng)直播中的彈幕交互是用戶和主播互動(dòng)的主要方式,實(shí)際上就是IM中的聊天室功能。聊天室和群聊功能類似,但聊天室的消息是不需要分發(fā)給不在線的用戶的,歷史消息也不需要查看,用戶只有進(jìn)入聊天室后才能查看聊天消息和群成員信息。面對(duì)復(fù)雜多變的網(wǎng)絡(luò)狀況,還需要根據(jù)用戶位置就近選擇近對(duì)應(yīng)運(yùn)營商的單線機(jī)房接入彈幕消息服務(wù),讓彈幕更及時(shí)。

            2、禮物系統(tǒng)

            送禮物的形式增強(qiáng)了用戶和主播之間的互動(dòng)交流,也是主播依賴平臺(tái)的最主要原因。禮物的收發(fā)在技術(shù)實(shí)現(xiàn)上也是用聊天室接口做的,通常采用IM中的自定義消息實(shí)現(xiàn),當(dāng)用戶收到或發(fā)送禮物時(shí)將自定義消息對(duì)應(yīng)的禮物圖形渲染出來。

            禮物的收發(fā)在技術(shù)實(shí)現(xiàn)上也是用聊天室接口做的,通常采用IM中的自定義消息實(shí)現(xiàn),當(dāng)用戶收到或發(fā)送禮物時(shí)將自定義消息對(duì)應(yīng)的禮物圖形渲染出來。
          附:(聊天室與禮物系統(tǒng) 到現(xiàn)在幾乎都是標(biāo)配)



          評(píng)論


          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();