整合營(yíng)銷(xiāo)服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢(xún)熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢(xún)熱線：
2017 年 12 月，微信小程序向開(kāi)發(fā)者開(kāi)放了實(shí)時(shí)音視頻能力，給業(yè)內(nèi)帶來(lái)廣闊的想象空間。連麥互動(dòng)視頻直播技術(shù)在 2016 年直播風(fēng)口中成為視頻直播的標(biāo)配，然而只有在原生的 APP 上才能保障良好的用戶(hù)體驗(yàn)。
那時(shí)候，在微信小程序中無(wú)法進(jìn)行實(shí)時(shí)音視頻互動(dòng)。微信小程序在去年 12 月宣布開(kāi)放實(shí)時(shí)音視頻能力，再加上去年 6 月蘋(píng)果宣布即將支持 WebRTC，業(yè)內(nèi)一下子千樹(shù)萬(wàn)樹(shù)梨花開(kāi)，前途一片光明。
連麥互動(dòng)直播技術(shù)和微信小程序以及 WebRTC 能產(chǎn)生怎么樣的化學(xué)作用？開(kāi)發(fā)者在微信小程序或者瀏覽器 WebRTC 上實(shí)現(xiàn)連麥互動(dòng)直播技術(shù)的時(shí)候，需要知道什么和考慮什么？
連麥視頻直播的客戶(hù)端主要包括：原生 APP、瀏覽器 H5、瀏覽器 WebRTC、微信小程序。瀏覽器上的應(yīng)用包括 H5 和 WebRTC，前者可以拉流觀看，后者可以實(shí)現(xiàn)推流和拉流。
原生 APP 終端音視頻引擎的結(jié)構(gòu)框圖如下，基本包括了音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸，合稱(chēng)實(shí)時(shí)語(yǔ)音視頻終端引擎。這里還包含底層的音視頻采集和渲染，還有網(wǎng)絡(luò)的輸入輸出能力，這是操作系統(tǒng)開(kāi)放的能力。
原生 APP 有個(gè)天然的好處，它是直接和操作系統(tǒng)打交道的，操作系統(tǒng)開(kāi)放的資源和能力它都可以直接用，比如說(shuō)音視頻的采集渲染，還有網(wǎng)絡(luò)的輸入輸出。套用一句時(shí)髦的廣告語(yǔ)：“沒(méi)有中間商賺差價(jià)”，直接和操作系統(tǒng)對(duì)接，可以獲得比較好的用戶(hù)體驗(yàn)。
在原生 APP 上實(shí)現(xiàn)連麥直播的優(yōu)勢(shì)是，對(duì)上面所說(shuō)的七個(gè)環(huán)節(jié)有較好的把控，可以獲得比較低的延遲，能自研實(shí)現(xiàn)語(yǔ)音前處理 3A 算法，包括回聲消除，還有對(duì)抖動(dòng)緩沖策略和碼率自適應(yīng)的策略都有比較好的把控。另外，可以自主選擇使用 RTMP 協(xié)議還是基于 UDP 的私有協(xié)議，對(duì)抗弱網(wǎng)環(huán)境更加有保障。
市面上比較流行的前處理技術(shù)，比如美顏、掛件、變聲等，原生 APP 都可以通過(guò)開(kāi)放前處理接口讓開(kāi)發(fā)者實(shí)現(xiàn)或者對(duì)接這些技術(shù)。為什么要強(qiáng)調(diào)這個(gè)呢？因?yàn)闉g覽器 WebRTC 和微信小程序都沒(méi)有開(kāi)放前處理接口，開(kāi)發(fā)者沒(méi)有辦法自行實(shí)現(xiàn)或者對(duì)接第三方的美顏或者掛件等技術(shù)模塊。
在原生 APP 上，開(kāi)發(fā)者可以得到全面的把控能力，讓用戶(hù)可以獲得更好的體驗(yàn)。主流的視頻直播平臺(tái)都有自己的原生 APP 平臺(tái)，而瀏覽器和微信小程序相對(duì)來(lái)說(shuō)是輔助的。原生 APP 的用戶(hù)體驗(yàn)是最好的，而且對(duì)開(kāi)發(fā)者來(lái)說(shuō)也是最可控的。
在原生 APP 上實(shí)現(xiàn)連麥直播的劣勢(shì)是什么呢？開(kāi)發(fā)門(mén)檻高，開(kāi)發(fā)周期長(zhǎng)、人力成本高。另外，從獲取用戶(hù)和傳播的角度來(lái)講，也沒(méi)有瀏覽器和微信小程序那么便利。
瀏覽器 H5 就像一個(gè)硬幣有兩面，有好處也有劣勢(shì)，好處是開(kāi)發(fā)成本低，容易傳播，劣勢(shì)是只能拉流，不能推流，不能做到多個(gè)用戶(hù)連麥直播。另外，在瀏覽器 H5 上延遲也是比較大。如果使用 RTMP 或者 HTTP-FLV，延遲會(huì)在 1 秒到 3 秒之間，如果用 HLS 延遲會(huì)大于 8 秒甚至 10 秒，這么大的延遲就根本就不允許實(shí)現(xiàn)連麥直播。
使用這三種協(xié)議都是通過(guò)瀏覽器 H5 中的播放器來(lái)播放的。在多主播連麥互動(dòng)的場(chǎng)景中，一個(gè)播放器里面只能播一路視頻流，三個(gè)主播就得三個(gè)播放器，因此看不到多個(gè)主播同框連麥互動(dòng)的情形。如果要看到多個(gè)主播同框互動(dòng)的畫(huà)面，就必須把多路流混合成一路流，在單個(gè)播放器里面播放。
另外，瀏覽器 H5 的源代碼是開(kāi)放的。如果在瀏覽器上把音視頻終端引擎實(shí)現(xiàn)了，相當(dāng)于對(duì)外公開(kāi)了所有核心的源代碼。因此，還沒(méi)有見(jiàn)過(guò)哪個(gè)廠商在瀏覽器 H5 上完整地把音視頻引擎真正做出來(lái)。即使你愿意做出來(lái)，瀏覽器也不會(huì)允許你這樣做，開(kāi)發(fā)者和操作系統(tǒng)之間隔著瀏覽器，如果瀏覽器不把操作系統(tǒng)的核心能力開(kāi)放給開(kāi)發(fā)者，開(kāi)發(fā)者就不能自主采集和渲染，不能掌控網(wǎng)絡(luò)輸入輸出，類(lèi)似流控碼控等功能無(wú)法實(shí)現(xiàn)。
在瀏覽器 H5 中也可以通過(guò) websocket 來(lái)傳輸，用 jsmpeg 來(lái)播放，視頻編解碼的格式用 mpeg1。
mpeg1 是一個(gè)比較老的媒體格式，所有瀏覽器都支持。在瀏覽器中使用 jsmpeg 播放器播放 mpeg1，所有瀏覽器也可以支持。這么做可以獲得比較低的延遲，但是還是無(wú)法推流，沒(méi)辦法實(shí)現(xiàn)連麥直播。
大家可能會(huì)覺(jué)得很遺憾，瀏覽器 H5 雖然很容易傳播，開(kāi)發(fā)簡(jiǎn)單但是體驗(yàn)欠佳，不能連麥直播。那么在瀏覽器上能不能推流，能不能實(shí)現(xiàn)連麥直播呢？答案是可以的，那就要用到 WebRTC。
這里說(shuō)的 WebRTC 是指已經(jīng)被內(nèi)嵌到瀏覽器里面，被瀏覽器支持的 WebRTC，而不是 WebRTC 的源代碼。部分主流瀏覽器內(nèi)嵌了 WebRTC，對(duì)開(kāi)發(fā)者開(kāi)放了瀏覽器的實(shí)時(shí)音視頻能力。
上圖是 WebRTC 的結(jié)構(gòu)圖。我們可以看到 WebRTC 包括了音頻引擎，視頻引擎、傳輸引擎等，最底層的虛線框表示可以重載，也就是說(shuō)瀏覽器把最底層的音視頻渲染和網(wǎng)絡(luò)傳輸?shù)牡讓幽芰﹂_(kāi)放給開(kāi)發(fā)者，開(kāi)發(fā)者可以根據(jù)自己的需求選擇是否進(jìn)行重載。音頻引擎中，包括了兩個(gè)編解碼器：iSAC 和 iLBC，前者針對(duì)寬帶和超寬帶的音頻編解碼，后者針對(duì)窄帶音頻編解碼。
音頻引擎還包括了音頻抖動(dòng)緩沖，回聲消除和噪音抑制模塊等。抖動(dòng)緩沖中的 NetEQ 算法可以說(shuō)是 WebRTC 里面的精華之一。
視頻引擎中，包括了 VP8 和 VP9 的視頻編解碼器，甚至是即將到來(lái)的 AV1。視頻引擎還包括視頻抖動(dòng)緩沖和圖像質(zhì)量增強(qiáng)等模塊。傳輸引擎，WebRTC 使用的是 SRTP（Secured Realtime Transport Protocol）安全實(shí)時(shí)傳輸協(xié)議。
最后，WebRTC 采取 P2P 的通信方式，沒(méi)有媒體服務(wù)器等后端的實(shí)現(xiàn)。以上是 WebRTC 的簡(jiǎn)單介紹。
瀏覽器 WebRTC 一般的優(yōu)勢(shì)和劣勢(shì)這里就不再重復(fù)，請(qǐng)大家自行百度，這里只說(shuō)重點(diǎn)。瀏覽器 WebRTC 的好處就是實(shí)現(xiàn)了相對(duì)完整的音視頻終端引擎，允許在瀏覽器上推流，可以實(shí)現(xiàn)連麥直播。
然而，瀏覽器 WebRTC 也有不足：
由于 WebRTC 不提供媒體服務(wù)器的實(shí)現(xiàn)，因此需要把瀏覽器 WebRTC 接入到媒體服務(wù)器后端，這個(gè)可以是自研的，也可以是第三方的服務(wù)。瀏覽器 WebRTC 和媒體服務(wù)器后端之間的協(xié)議和媒體格式是不一樣的，因此要做協(xié)議和格式的轉(zhuǎn)換。WebRTC 用的基于 UDP 的 SRTP，需要把它轉(zhuǎn)換成媒體服務(wù)器的基于 UDP 的私有協(xié)議。另外，媒體格式也需要轉(zhuǎn)換，因?yàn)?WebRTC 中語(yǔ)音視頻格式默認(rèn)用的是 VP8 或者 VP9。同時(shí)實(shí)時(shí)傳輸網(wǎng)絡(luò)中有關(guān)信令調(diào)度也需要做一些調(diào)整。瀏覽器 WebRTC 和媒體服務(wù)器后端之間的接入層也可以采用開(kāi)源的 WebRTC Gateway（比如說(shuō) janus）來(lái)實(shí)現(xiàn)。
瀏覽器是類(lèi)似操作系統(tǒng)的一種超級(jí)應(yīng)用，它坐擁重要的流量入口，然而它也是開(kāi)發(fā)者和操作系統(tǒng)之間的“中間商”。開(kāi)發(fā)者通過(guò) WebRTC 獲得瀏覽器開(kāi)放的實(shí)時(shí)音視頻能力，然而也必須要承受 WebRTC 帶來(lái)的痛苦。
微信小程序是什么？是跑在微信上面的輕型應(yīng)用。微信是什么？是類(lèi)操作系統(tǒng)的超級(jí)應(yīng)用。這些特征和瀏覽器以及 H5 是不是很接近？H5 是瀏覽器支持的輕型應(yīng)用，而瀏覽器是類(lèi)操作系統(tǒng)的超級(jí)應(yīng)用。瀏覽器背后是各大國(guó)際科技巨頭，不像微信這樣背后只有騰訊一個(gè)互聯(lián)網(wǎng)巨頭。因此，從這個(gè)角度來(lái)看，微信小程序、瀏覽器 WebRTC 和 H5 是有相通之處的。
微信小程序可以類(lèi)比為瀏覽器 H5 那樣的客戶(hù)端和服務(wù)器的結(jié)構(gòu)。其中 HTML 對(duì)應(yīng)微信小程序的 WXML，CSS 對(duì)應(yīng)小程序的 WXSS，小程序的腳本語(yǔ)言和 JS 是一樣的，只是框架不一樣。微信小程序提供了兩個(gè)標(biāo)簽，一個(gè)是<live-pusher>，一個(gè)是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以實(shí)現(xiàn)單向直播或者連麥直播。小程序提供兩種模式：LIVE 和 RTC，LIVE 支持單向直播，RTC 支持低延遲的連麥直播。目前微信小程序推流采用 RTMP 協(xié)議，如果要和私有協(xié)議互通，需要進(jìn)行協(xié)議轉(zhuǎn)換。
微信小程序開(kāi)放了實(shí)時(shí)音視頻能力，對(duì)業(yè)界來(lái)說(shuō)是重大利好。然而，根據(jù)上面的信息和邏輯，我們也看到采用微信小程序?qū)崿F(xiàn)連麥互動(dòng)直播的好處和不足。
好處有三點(diǎn)：
不足有四點(diǎn)：
瀏覽器通過(guò) WebRTC 開(kāi)放了瀏覽器的實(shí)時(shí)音視頻能力，而微信通過(guò)小程序開(kāi)放了微信的實(shí)時(shí)音視頻能力，在兩個(gè)類(lèi)操作系統(tǒng)的平臺(tái)上允許開(kāi)發(fā)者去實(shí)現(xiàn)連麥直播和實(shí)時(shí)音視頻通話(huà)。然而，無(wú)論 WebRTC 還是小程序只是在終端上帶你入門(mén)，對(duì)開(kāi)發(fā)者來(lái)說(shuō)，要真正實(shí)現(xiàn)整套系統(tǒng)，還有很多工作需要做的。
如果要將微信小程序接入實(shí)時(shí)音視頻傳輸網(wǎng)絡(luò)，中間得有接入服務(wù)器，我們叫接入層。在接入層我們需要做協(xié)議的轉(zhuǎn)換，比如說(shuō)，如果實(shí)時(shí)音視頻傳輸網(wǎng)絡(luò)是使用基于 UDP 的私有協(xié)議，那么要把 RTMP 協(xié)議轉(zhuǎn)為基于 UDP 的私有協(xié)議。還有媒體格式的轉(zhuǎn)換，如果和實(shí)時(shí)傳輸網(wǎng)絡(luò)的媒體格式不一樣，還需要進(jìn)行轉(zhuǎn)換。
還有別的方法在小程序上做連麥直播互動(dòng)嗎？必須要使用微信小程序開(kāi)放的語(yǔ)音視頻能力嗎？也不一定。下圖展示了我在市面上看過(guò)的一個(gè)技術(shù)方案，它繞過(guò)了微信小程序?qū)崟r(shí)語(yǔ)音視頻能力，通過(guò)微信小程序 WebView 組件實(shí)現(xiàn)了連麥直播的方案。這里和大家分享一下。
這個(gè)方案的基本思路是利用 WebView 的瀏覽器特點(diǎn)，在 WebView 內(nèi)使用 WebRTC 的 Web API，從而在小程序上獲得實(shí)時(shí)音視頻能力。上圖是這個(gè)方案的架構(gòu)圖。最底層是微信小程序的基礎(chǔ)能力。上一層是 WebView，微信小程序的 WebView 類(lèi)似瀏覽器，那么就可能會(huì)支持 WebRTC。然而必須要注意到，微信小程序的 WebView 在安卓平臺(tái)上支持 WebRTC，但在 iOS 平臺(tái)上面不支持 WebRTC。
雖然這個(gè)方案理論上也能在微信小程序上實(shí)現(xiàn)連麥直播，但是它有以下的局限性：
這個(gè)方案本質(zhì)上還是一個(gè)基于 WebRTC 的解決方案，沒(méi)有用到微信小程序開(kāi)放的實(shí)時(shí)音視頻能力，而是快速地借助 WebView 組件，劍走偏鋒，十分討巧地在微信小程序里使用了 WebRTC。
連麥直播技術(shù)逐步在原生 APP, 瀏覽器 H5，瀏覽器 WebRTC，微信小程序上延伸，衍生出更加豐富的生態(tài)，提供更加便捷和良好的用戶(hù)體驗(yàn)，對(duì)視頻直播平臺(tái)和用戶(hù)來(lái)說(shuō)是好消息。然而，欲帶皇冠，必承其重。特別是在瀏覽器 WebRTC 和微信小程序上，開(kāi)發(fā)者要充分理解這些類(lèi)型終端的特點(diǎn)和局限，才能更好地在上面利用連麥直播技術(shù)進(jìn)行創(chuàng)新，服務(wù)用戶(hù)。
附上一份音視頻學(xué)習(xí)課程大綱給大家
然Flash播放器為互聯(lián)網(wǎng)互動(dòng)立下汗馬功勞，但不得不承認(rèn)其插件在性能和安全性上都已經(jīng)遠(yuǎn)遠(yuǎn)落后時(shí)代，跨設(shè)備體驗(yàn)糟糕透頂。在Youtube于今年初將默認(rèn)網(wǎng)頁(yè)視頻轉(zhuǎn)換成HTML5后，亞馬遜旗下的知名游戲直播平臺(tái)Twitch也開(kāi)始從Flash向HTML5邁步。據(jù)稱(chēng)，雖然視頻仍然為Flash格式播放，但目前Twitch的默認(rèn)播放控件已經(jīng)全面轉(zhuǎn)換成HTML5播放器，“這是實(shí)現(xiàn)全面轉(zhuǎn)換的重要一步。”
相信有不少熱衷于游戲的玩家經(jīng)常在Twitch上收看玩家的游戲直播，相信轉(zhuǎn)換至HTML5播放器后Twitch的流暢度和安全性會(huì)提升不少，播放界面也已經(jīng)經(jīng)過(guò)全新設(shè)計(jì)，簡(jiǎn)潔便利不少，自適應(yīng)比特率功能也能夠讓玩家更流暢地根據(jù)自身網(wǎng)速收看直播。
(來(lái)源：cnbeta）
鋒網(wǎng)按：本文作者蔣海兵，趣拍產(chǎn)品總監(jiān)，直播行業(yè)老兵。
移動(dòng)直播行業(yè)的火熱會(huì)在很長(zhǎng)一段時(shí)間內(nèi)持續(xù)，通過(guò)和各行業(yè)的整合，從而成為具有無(wú)限可能性的行業(yè)。主要有以下三個(gè)原因：
第一，移動(dòng)直播的UGC生產(chǎn)模式比PC端的直播更明顯，人人都有設(shè)備，隨時(shí)隨地開(kāi)播，完全順應(yīng)了互聯(lián)網(wǎng)時(shí)代的開(kāi)放性原則，能刺激更多人去創(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)造出更加豐富的用戶(hù)體驗(yàn)。直播可以以SDK的形式接入到自己的應(yīng)用中，比如，教育領(lǐng)域中的課后輔導(dǎo)完全可以以直播的形式開(kāi)展業(yè)務(wù)、電商也可借助直播讓用戶(hù)挑選商品，促進(jìn)銷(xiāo)售。
第三，一個(gè)與VR/AR技術(shù)相結(jié)合的移動(dòng)直播為整個(gè)行業(yè)的未來(lái)提供了新的發(fā)展空間。VR/AR直播能夠讓用戶(hù)身臨其境，帶動(dòng)主播與觀眾更貼近真實(shí)的互動(dòng)，大大提高平臺(tái)的用戶(hù)參與度。
當(dāng)下，有技術(shù)實(shí)力和流量?jī)?yōu)勢(shì)的互聯(lián)網(wǎng)從業(yè)者都不愿錯(cuò)過(guò)直播這個(gè)風(fēng)口，如何快速搭建一個(gè)直播系統(tǒng)成了大家關(guān)心的問(wèn)題，我想和大家分享下我的經(jīng)驗(yàn)。我從事于一家直播產(chǎn)品開(kāi)發(fā)商，我們的產(chǎn)品為了快速趕上市場(chǎng)，使用了云服務(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é)所做的工作。
直播推流端即主播端，主要通過(guò)手機(jī)攝像頭采集視頻數(shù)據(jù)和麥克風(fēng)采集音頻數(shù)據(jù)，經(jīng)過(guò)一系列前處理、編碼、封裝，然后推流到CDN進(jìn)行分發(fā)。
移動(dòng)直播SDK通過(guò)手機(jī)攝像頭和麥克風(fēng)直接采集音視頻數(shù)據(jù)。其中，視頻采樣數(shù)據(jù)一般采用RGB或YUV格式、音頻采樣數(shù)據(jù)一般采用PCM格式。采集到的原始音視頻的體積是非常大的，需要經(jīng)過(guò)壓縮技術(shù)處理來(lái)提高傳輸效率。
在這個(gè)環(huán)節(jié)主要處理美顏、水印、模糊等效果。美顏功能幾乎是直播的標(biāo)配功能。我們調(diào)研中發(fā)現(xiàn)太多case是因?yàn)闆](méi)有美顏功能被拋棄使用的。另外國(guó)家明確提出了，所有直播都必須打有水印并回放留存15天以上。
美顏實(shí)際上是通過(guò)算法去識(shí)別圖像中的皮膚部分，對(duì)皮膚區(qū)域進(jìn)行色值調(diào)整。通過(guò)顏色對(duì)比找到皮膚區(qū)域，可以進(jìn)行色值調(diào)整、添加白色圖層或調(diào)整透明度等來(lái)達(dá)到美白效果。在美顏處理方面，最著名的GPUImage提供了豐富的效果，同時(shí)可以支持iOS和Android，支持自己寫(xiě)算法實(shí)現(xiàn)自己最理想的效果。GPUImage內(nèi)置了120多種常見(jiàn)濾鏡效果，添加濾鏡只需要簡(jiǎn)單調(diào)用幾行代碼就可以了。
為了便于手機(jī)視頻的推流、拉流以及存儲(chǔ)，通常采用視頻編碼壓縮技術(shù)來(lái)減少視頻的體積，現(xiàn)在比較常用的視頻編碼是H.264。在音頻方面，比較常用的是AAC編碼格式，其它如MP3、WMA也是可選方案。視頻經(jīng)過(guò)編碼壓縮大大提高了視頻的存儲(chǔ)和傳輸效率，當(dāng)然，經(jīng)過(guò)壓縮后的視頻在播放時(shí)必須進(jìn)行解碼。
相較于之前的H.264，2012年誕生的H.265編解碼標(biāo)準(zhǔn)有了相當(dāng)大的改善，做到了僅需要原來(lái)一半帶寬即可播放相同質(zhì)量的視頻，低于1.5Mbps的網(wǎng)絡(luò)也能傳輸1080p的高清視頻。像阿里云、金山云都在推自己的H.265編解碼技術(shù)，隨著直播的快速發(fā)展和對(duì)帶寬的依賴(lài)，H.265編解碼技術(shù)已有全面取代H.264的趨勢(shì)。
H264和H265個(gè)模塊技術(shù)差異：
另外，硬件編碼已經(jīng)成為移動(dòng)直播的首選方案，軟編碼處理在720p以上的視頻頹勢(shì)非常明顯。在iOS平臺(tái)上硬件編碼的兼容性比較好，可以直接采用，但在Android平臺(tái)上，Media Codec編碼器針對(duì)不同的芯片平臺(tái)表現(xiàn)差異還是非常大的，要完全實(shí)現(xiàn)全平臺(tái)兼容的成本還是非常高的。
要想用于推流還必須把音視頻數(shù)據(jù)使用傳輸協(xié)議進(jìn)行封裝，變成流數(shù)據(jù)。常用的流傳輸協(xié)議有RTSP、RTMP、HLS等，使用RTMP傳輸?shù)难訒r(shí)通常在1–3秒，對(duì)于移動(dòng)直播這種實(shí)時(shí)性要求非常高的場(chǎng)景，RTMP也成為移動(dòng)直播中最常用的流傳輸協(xié)議。最后通過(guò)一定的Qos算法將音視頻流數(shù)據(jù)推送到網(wǎng)絡(luò)斷，通過(guò)CDN進(jìn)行分發(fā)。在直播場(chǎng)景中，網(wǎng)絡(luò)不穩(wěn)定是非常常見(jiàn)的，這時(shí)就需要Qos來(lái)保證網(wǎng)絡(luò)不穩(wěn)情況下的用戶(hù)觀看直播的體驗(yàn)，通常是通過(guò)主播端和播放端設(shè)置緩存，讓碼率均勻。另外，針對(duì)實(shí)時(shí)變化的網(wǎng)絡(luò)狀況，動(dòng)態(tài)碼率和幀率也是最常用的策略。
當(dāng)然，在網(wǎng)絡(luò)傳輸方面全部自己來(lái)做基本不現(xiàn)實(shí)，找提供推流服務(wù)的CDN服務(wù)商提供解決方案是最好的選擇。據(jù)了解，阿里云是國(guó)內(nèi)唯一能自研CDN緩存服務(wù)器的廠商，性能非常有保障。當(dāng)然，大多數(shù)直播平臺(tái)都會(huì)同時(shí)接入多個(gè)視頻云服務(wù)提供商，這樣可以做拉流線路互備，對(duì)推流后視頻集群再進(jìn)行優(yōu)化也可提高直播的流暢性和穩(wěn)定性。
要想適配各終端和平臺(tái)，服務(wù)端還需要對(duì)流進(jìn)行轉(zhuǎn)碼，如支持RTMP、HLS、FLV等格式拉流，支持一路轉(zhuǎn)多路適配不同網(wǎng)絡(luò)和分辨率的終端設(shè)備。
像阿里云等云服務(wù)商都提供了實(shí)時(shí)轉(zhuǎn)碼技術(shù)，將用戶(hù)推流碼率較高（比如720P）實(shí)時(shí)轉(zhuǎn)化成較低清晰度（比如360P）的流以適應(yīng)播放端的需求。如果要自己搭建實(shí)時(shí)轉(zhuǎn)碼系統(tǒng)，這個(gè)成本是極高的，一臺(tái)8核設(shè)備只能實(shí)時(shí)轉(zhuǎn)10路流，如果一個(gè)正常的直播平臺(tái)有1000路流，就需要100臺(tái)設(shè)備，加上后期的運(yùn)維成本，一般公司就吃不消了。
2016年4月14日，文化部查出了斗魚(yú)、虎牙、YY、熊貓TV、六間房、9158等涉嫌提供含宣揚(yáng)淫穢、暴力、教唆犯罪的網(wǎng)絡(luò)直播平臺(tái)，被列入查處名單。政府介入管制有利于直播行業(yè)打造健康的生態(tài)，進(jìn)入良性發(fā)展。這也意味著為了安全直播產(chǎn)品鑒黃成了必需環(huán)節(jié)，使用技術(shù)手段去鑒黃是移動(dòng)直播平臺(tái)必然采用的方案。
市面上提供鑒黃服務(wù)的方案主要有兩種：
第一種是對(duì)視頻進(jìn)行截圖，然后對(duì)圖片進(jìn)行鑒黃，返回鑒黃結(jié)果和分值。典型的企業(yè)有阿里（綠網(wǎng)）、圖譜科技，他們目前都支持直接傳入視頻，經(jīng)過(guò)服務(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ì)高一些。
還有一種一站式直播解決方案提供商，他們的做法是，用戶(hù)只需在控制臺(tái)對(duì)鑒黃服務(wù)進(jìn)行配置就可以針對(duì)每個(gè)應(yīng)用、每一路直播流進(jìn)行實(shí)時(shí)審核。在控制臺(tái)中，云服務(wù)商實(shí)時(shí)將鑒黃結(jié)果返回，用戶(hù)可以直接查看色情直播和違規(guī)界面的截圖，同時(shí)可以對(duì)直播流進(jìn)行控制，切斷問(wèn)題直播流。該服務(wù)商還提供了短信、郵件和站內(nèi)信功能，避免漏掉任何一個(gè)非法視頻，給平臺(tái)造成損失，我們就使用了這種方式。
在播放器端如何做到秒開(kāi)，直播過(guò)程中保證畫(huà)面和聲音清晰度的同時(shí)，穩(wěn)定、流程、無(wú)卡頓的直播流量，這些工作都需要播放器端配合服務(wù)端來(lái)做優(yōu)化，做到精確調(diào)度。
拉流實(shí)際是推流的逆過(guò)程。首先通過(guò)播放端獲取碼流，標(biāo)準(zhǔn)的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專(zhuān)利協(xié)議，開(kāi)源軟件和開(kāi)源庫(kù)都支持的比較好，如開(kāi)源的librtmp庫(kù)，播放端只要支持flashPlayer的就能非常簡(jiǎn)單的播放RTMP直播，直播延遲一般在1–3秒。
HLS是蘋(píng)果提出的基于HTTP的流媒體傳輸協(xié)議，HTML5可以直接打開(kāi)播放，通過(guò)微信、QQ等軟件分享出去，用戶(hù)也可以直接觀看直播，可以說(shuō)移動(dòng)直播app，HLS拉流協(xié)議是必須支持的，缺點(diǎn)是延遲通常大于10秒。FLV（HTTP-FLV）協(xié)議是使用HTTP協(xié)議傳輸流媒體內(nèi)容的一個(gè)協(xié)議，也不用擔(dān)心被Adobe的專(zhuān)利綁架，直播延遲同樣可以做到1–3秒。
各拉流協(xié)議的差異：
我們使用的云服務(wù)的直播拉流技術(shù)提供了以上三種格式，滿(mǎn)足不同業(yè)務(wù)場(chǎng)景的需求，如對(duì)即時(shí)性要求較高或有互動(dòng)需求的可以采用RTMP或FLV格式進(jìn)行直播拉流播放；對(duì)于有回放或跨平臺(tái)需求的，推薦使用HLS。當(dāng)然，三種協(xié)議是可以同時(shí)使用的，分別用到自己的場(chǎng)景就可以了。
拉流獲取封裝的視頻數(shù)據(jù)后，必須通過(guò)解碼器解碼、渲染后才能在播放器上播放。它是編碼的逆過(guò)程，是指從音視頻的數(shù)據(jù)中提取原始數(shù)據(jù)。前面介紹的H.264和H.265編碼格式都是有損壓縮，所以在提取后的原始數(shù)據(jù)，并非原始采樣數(shù)據(jù)，存在一定的信息丟失。因此，在視頻體積最小的情況下通過(guò)各種編碼參數(shù)保留最好的原始畫(huà)面，成為了各視頻公司的核心機(jī)密。
考慮對(duì)高清的支持，解碼肯定還是要選擇硬解碼的。前面介紹過(guò)，iOS系統(tǒng)由于硬件比較單一、比較封閉，支持的比較好，Android系統(tǒng)由于平臺(tái)差異非常大，編解碼要完全兼容各平臺(tái)還需要很多工作要做。
移動(dòng)直播中最常見(jiàn)的交互有聊天室（彈幕）、點(diǎn)贊、打賞和禮物等，交互系統(tǒng)涉及消息的實(shí)時(shí)性和互動(dòng)性，在技術(shù)實(shí)現(xiàn)上大多是使用IM的功能來(lái)實(shí)現(xiàn)的。對(duì)于在線人數(shù)比較多的房間，彈幕消息量是非常大，主播與用戶(hù)其實(shí)都看不過(guò)來(lái)，為了緩解服務(wù)器壓力，在產(chǎn)品策略需要做一些必要的優(yōu)化。
移動(dòng)直播中的彈幕交互是用戶(hù)和主播互動(dòng)的主要方式，實(shí)際上就是IM中的聊天室功能。聊天室和群聊功能類(lèi)似，但聊天室的消息是不需要分發(fā)給不在線的用戶(hù)的，歷史消息也不需要查看，用戶(hù)只有進(jìn)入聊天室后才能查看聊天消息和群成員信息。面對(duì)復(fù)雜多變的網(wǎng)絡(luò)狀況，還需要根據(jù)用戶(hù)位置就近選擇近對(duì)應(yīng)運(yùn)營(yíng)商的單線機(jī)房接入彈幕消息服務(wù)，讓彈幕更及時(shí)。
禮物系統(tǒng)更是絕大多數(shù)移動(dòng)直播平臺(tái)的標(biāo)配了，它是這些平臺(tái)主要的收入來(lái)源。送禮物的形式也增強(qiáng)了用戶(hù)和主播之間的互動(dòng)交流，也是主播依賴(lài)平臺(tái)的最主要原因。
禮物的收發(fā)在技術(shù)實(shí)現(xiàn)上也是用聊天室接口做的，通常采用IM中的自定義消息實(shí)現(xiàn)，當(dāng)用戶(hù)收到或發(fā)送禮物時(shí)將自定義消息對(duì)應(yīng)的禮物圖形渲染出來(lái)。
以上就是我們?cè)谑褂昧说谌絊DK服務(wù)后總結(jié)出來(lái)的直播產(chǎn)品經(jīng)驗(yàn)，希望能幫助到創(chuàng)業(yè)者和從業(yè)者們。
*請(qǐng)認(rèn)真填寫(xiě)需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
