摘要： 在2017年4月22日舉行的『LiveVideoStack Meet北京：后直播時代技術(shù)』沙龍上，北京密境和風(fēng)科技有限公司（花椒直播）的iOS技術(shù)負(fù)責(zé)人唐賡首次對外分享了花椒直播App端的技術(shù)演進(jìn)過程，涉及到花椒直播從無到有，不斷演進(jìn)中的方方面面，在業(yè)務(wù)不斷的要求下，唐賡和他的團(tuán)隊需要快速試錯，找到最適當(dāng)?shù)募夹g(shù)方案。本文根據(jù)唐賡的分享整理而成。
文 / 唐賡
整理 / LiveVideoStack
點(diǎn)擊觀看演講視頻，關(guān)注LiveVideoStack，回復(fù)『0422資料』，獲得此次此次分享的資料下載地址。
本文主要分為以下部分：
直播興起的歷史
摸索學(xué)習(xí)階段
基本情況
技術(shù)問題
秀場直播階段
趟過的坑和解決過的問題
直播的底層技術(shù)
互動秀場階段
在經(jīng)歷了野蠻發(fā)展的2016直播大戰(zhàn)后，App端的技術(shù)扮演越來越重要的角色，好的技術(shù)可以讓App在大量同質(zhì)化的直播App中脫穎而出，讓用戶體驗和用戶留存率顯著提升。
互聯(lián)網(wǎng)老碼農(nóng)、朝陽區(qū)老群眾唐賡將在本次分享上介紹花椒直播App在手機(jī)端技術(shù)的探索和實踐、以及對未來的展望和思考。本文將涉及265、GPU技術(shù)、游戲級交互引擎、人工智能、深度學(xué)習(xí)等技術(shù)在直播中的應(yīng)用和展望。
一、直播興起的歷史
如今，隨著直播平臺如雨后春筍般的興起，一旦有大事件發(fā)生，新聞采訪時都是下面這樣的：
上面這張圖攝于2015年，我們也是其中之一。隨著國外直播平臺PeriScope和Meercat的成功，國人也發(fā)現(xiàn)了其中的機(jī)遇，于是紛紛效仿。
映客和花椒是國內(nèi)起步較早的直播平臺，后面又有各種各樣的其它平臺出現(xiàn)。
二、摸索學(xué)習(xí)階段
基本情況
初期，我們的很多基本體驗都是基于模仿的，甚至初期我們是完全照搬了MeerCat的模式。
最初的內(nèi)容比較繁雜，囊括了各種信息，包括達(dá)人才藝展示、授課、烹飪、雜耍等?；镜慕换シ绞骄褪屈c(diǎn)贊、分享、文字交流以及視頻，我們對自己的定位就是“視頻版微博”，包括界面的整體布局全都是效仿微博的，連按鈕位置和頁面布局都幾乎一模一樣。整個頁面的主要關(guān)注點(diǎn)在Feed流上面。
后在濾鏡比較火爆的時候，我們又加入了圖片濾鏡功能，然后又加入了自拍短視頻的功能。出于對社交的重視，我們又加入了私信功能。
在初期摸索階段，由于產(chǎn)品經(jīng)理以及開發(fā)人員對整個App的定位缺乏明確的認(rèn)識，我們只能采取跟風(fēng)做法，將市場上比較潮流的內(nèi)容一網(wǎng)打盡，全部加上去。
技術(shù)問題
在這個階段，大家所解決的都是類似的問題：
1、硬編硬解
我們分析過映客，結(jié)果發(fā)現(xiàn)映客所用的硬編硬解代碼與我們所使用的一模一樣，連臨時文件的文件名都一模一樣。原因在于：我們所使用的都是同一套開源代碼。
最初iOS8還不普及，大多設(shè)備都是iOS7系統(tǒng)，想要做硬編硬解只能依賴系統(tǒng)的MovieWriter那套API（從磁盤的MP4臨時文件中讀取編碼結(jié)果）。為了解決問題，當(dāng)時有一個外國人分享了一套開源編碼，解決了硬編硬解實現(xiàn)的問題，因此大家全都去用這套開源代碼。后來到了iOS8，由于原生支持硬編硬解，這個問題才不復(fù)存在。
2、看播花屏
類似的問題還有很多，現(xiàn)在看起來覺得很基礎(chǔ)的問題，當(dāng)時卻是很大的問題，比如看播花屏。丟了一幀再強(qiáng)行解碼，就會出現(xiàn)花屏的問題。解決方法很簡單，完全丟棄GoP里后續(xù)的內(nèi)容。
3、音視頻同步
根據(jù)我們對各家平臺的分析，所有直播平臺基本都不同步，只不過大家采用的方式各不相同。例如：將音頻視頻分開采集，并分別通過不同的通道進(jìn)行傳播。在此過程中，我們需要盡量保證音頻是連續(xù)的，視頻相對就沒那么重要，這樣就會導(dǎo)致音頻和視頻總有些不同步。解決辦法就是保證時間戳準(zhǔn)確。
我們讓QA測試是否同步的簡易辦法是，利用一支筆敲擊桌面，同時在視頻的那個瞬間，也必須要有聲音發(fā)出。相對于對口型等方式，這樣的方式更簡單也更直接。
當(dāng)然，我們也嘗試了很多其它方案，不過利用不同的方案去采集聲音，時間戳總會有些問題存在。在這個階段，我們做了很多嘗試，一個個解決掉了這些問題。
4、降低看播錄播CPU消耗、直播間CPU總消耗
起初我們并沒有意識到這個問題，結(jié)果上線后突然出現(xiàn)了卡頓等意外。經(jīng)過深入分析，我們發(fā)現(xiàn)這是由于CPU的消耗非常嚴(yán)重引起的。實際應(yīng)用與測試環(huán)境不同，由于實際環(huán)境下使用人數(shù)眾多，點(diǎn)贊、發(fā)言、送禮等操作都會對CPU造成巨大的消耗。
通過模擬，我們找到了各種各樣的性能瓶頸，并一點(diǎn)點(diǎn)地改進(jìn)。彼時大約有50%的因素是因為客戶端CPU消耗太高，導(dǎo)致推流時會出現(xiàn)卡頓。
5、回放／回放彈幕優(yōu)化
剩下的問題在于服務(wù)端，類似回放、回放的彈幕優(yōu)化等問題都有可能造成卡頓。
有一次我們請了范冰冰來做直播，平時的彈幕文件也就是幾兆而已，結(jié)果那次彈幕文件的大小達(dá)到了200多兆。讀取要花費(fèi)很久，即便讀取成功，下載的彈幕文件在載入時也會出現(xiàn)內(nèi)存超過限制，隨后閃退的情況。類似這樣的問題層出不窮，我們也只能一個個解決。
6、私有協(xié)議與公有協(xié)議、TCP與UDP
在這個階段，我們摸索了很長一段時間，包括究竟用私有協(xié)議還是公有協(xié)議，究竟用TCP還是UDP等等。不過事實上到現(xiàn)在，這些問題仍舊存在。我們的線上還是既有私有協(xié)議又有公有協(xié)議，既有TCP又有UDP。
私有協(xié)議的好處在于，我們可以肆無忌憚地加入各種各樣的功能，包括對其進(jìn)行優(yōu)化，性能調(diào)試等，但公有協(xié)議的好處在于它支持CDN，各家CDN都可以拿過來直接使用。我們自己的CDN只在國內(nèi)一些大城市有，像奧運(yùn)會這樣的活動，如果要去巴西，或者要去直播歐洲杯，都要借助其它的CDN。
TCP和UDP的問題在于：UDP的性能比TCP好得多，沒有超時重傳這些消耗。而且TCP還有一個問題，就是可靠連接的問題。它必須要確保數(shù)據(jù)到達(dá)，一旦出現(xiàn)阻塞，要想放棄的話就只能把鏈接斷掉。
7、回放錄制，HLS生成
一般來說，如果網(wǎng)絡(luò)不好的話，信息流經(jīng)常會出現(xiàn)斷裂以及缺失。如果錄制的回放中有缺失，生成HLS之后，通過一些私有播放器是可以正常播放的，但之前系統(tǒng)的播放器是無法播放這類視頻的。
當(dāng)時我們想了很多辦法，包括重整時間戳，進(jìn)行其它的處理，都是為了解決播放的問題。不過現(xiàn)在就沒關(guān)系了，用我們自己編寫的播放器來播放，是始終可以正常播放的。
8、秒開
放在以前，大家點(diǎn)進(jìn)去以后等一兩秒再打開，都覺得挺快了。但現(xiàn)在來講，超過三百毫秒都不合格。秒開應(yīng)當(dāng)是所有直播軟件必備的功能了。
在改進(jìn)時，我們通過抓包分析，了解從點(diǎn)擊到視頻的第一幀展現(xiàn)之間，都發(fā)生了哪些事情，再把所有不必要的東西全部拿掉。例如之前先點(diǎn)進(jìn)去的話，可能要去找對應(yīng)的流服務(wù)器，需要通過302跳轉(zhuǎn)。而現(xiàn)在在廣場上就把類似這些所有的必要信息全都拿到。點(diǎn)擊后，原本打開直播間時要加載頭像、豆幣等內(nèi)容，但為了實現(xiàn)秒開，這些全部要讓道，所有東西必須等到第一幀展現(xiàn)出來以后才開始進(jìn)行。
根據(jù)我們的分析，映客App做得更多一些。從手指向上滑的時候就開始切換，當(dāng)手指落點(diǎn)超過屏幕的1/3后，就會開始加載下一個直播。這樣一來，借助偷跑的零點(diǎn)幾秒，它的秒開性能更加優(yōu)越。
其它優(yōu)化問題還包括CDN優(yōu)化，使用成熟的CDN廠商會帶來更好的效果。比如映客的GoP就是一秒，我們的GoP是兩秒，都可能是因為相關(guān)的優(yōu)化問題。
9、用戶定位、調(diào)度
至于用戶定位和調(diào)度的優(yōu)化問題，有這樣的案例：某個人明明在美國，但我們采集到的IP定位顯示他在廣州，根據(jù)分析他實際是使用了廣州移動的sim卡漫游到美國。由于移動的原因，我們會顯示他的IP在廣州。
這種情況下，再去對他進(jìn)行調(diào)度，一定會出錯。我們經(jīng)常發(fā)生這種事情，比如有人特別卡，我們就會去看他實際所在的位置，是否跟我們將他調(diào)度所分配到的服務(wù)器不在同一個地方。
由于經(jīng)常發(fā)生類似問題，我們也形成了一套比較自動的補(bǔ)救機(jī)制。以前都是固定調(diào)度，調(diào)度以后在直播過程中就不能再更改了。但由于類似錯誤太多，我們修改了相應(yīng)機(jī)制，使其能夠在當(dāng)直播中重新調(diào)度，強(qiáng)制執(zhí)行一個離用戶最近的流服務(wù)器。
10、VR直播？
這個時間段，我們還嘗試了VR直播，那段時間VR特別火。為了增加這個功能，我們在客戶端增加了VR播放器，結(jié)果讓安裝包又?jǐn)U大了好幾兆，結(jié)果并不成功，這個屬于我們趟過的坑。
三、秀場直播階段
趟過的坑和解決過的問題
1、禮物系統(tǒng)
做了大半年之后，我們才找到一個比較好的定位，就是做秀場直播。既然是秀場直播，就得有秀場必須要有的東西，包括各種各樣的禮物，連發(fā)禮物、全屏禮物、私信禮物，實際上一加上這些東西，就又會遇到各種各樣的CPU問題。
怎么優(yōu)化這些CPU的占用？比如說，像用PNG序列(實現(xiàn)的禮物)----我們一個最大的PNG序列可能會有80幀甚至180幀，全部一起加載的話，一瞬間的CPU占用會非常高。一兩秒之內(nèi)，推流都會停止。類似這種情況，我們都是在性能分析階段才發(fā)現(xiàn)的。采用的解決方案是：讓圖片加載得慢一點(diǎn)，加幾幀之后就停一下。
2、金幣系統(tǒng)
金幣系統(tǒng)，我們也走了一些彎路。最早我們用的是單幣體系，就是整個世界里交易的只有一種東西，就是花椒豆。我送給你一百豆，你就拿到一百豆，當(dāng)然最終提現(xiàn)的時候會有一些手續(xù)費(fèi)。
但單幣體系有一個問題，就是你拿一百豆又可以送給我，我又可以再送給你，我們之間就可以無限刷下去。這樣會導(dǎo)致一個結(jié)果：在我們的整個體系里，無論經(jīng)驗值還是其它的，只要跟消費(fèi)量有關(guān)的東西，就可以隨便刷了。
其實大家在上線這個東西的時候，就已經(jīng)意識到可能會有這樣的問題，但由于缺乏經(jīng)驗，最終還是決定上了。之后就發(fā)現(xiàn)有人通過各種各樣的方式利用這個規(guī)則，因此我們趕緊改掉，用雙幣種的模式，送花椒豆給對方得用幣，再用幣來買豆或者提現(xiàn)的話，就得有一定的折損。
有了這樣的游戲規(guī)則以后，整個生態(tài)環(huán)境就變得健康多了。實際上這個彎路走得挺不值的，因為包括YY、映客等App，都早就采用了雙幣系統(tǒng)。
3、附近的人
這個也算一個坑。當(dāng)時這個功能我們都做了，后來又拿下了。原因在于：假設(shè)用戶位置定得過于精確，會讓主播產(chǎn)生顧慮——如果可以定位到哪個小區(qū)，別人在小區(qū)門口守著怎么辦？以前我們還有一個地圖視圖，可以在地圖上將用戶標(biāo)記出來。雖然有一定的誤差，但通過多收集幾個手機(jī)的數(shù)據(jù)，就有可能定位到具體的位置。
最后，我們還是采用了映客的方式，也就是九宮格頭像。在下面稍微標(biāo)注一下這個人距離你有多遠(yuǎn)，而且那個數(shù)字也是調(diào)整過的。地圖視圖對主播傷害很大，一般有這個功能，他們就不愿意用了。
4、美顏功能
美顏算是我們做得比較好的一個功能。這個功能并不是我們第一個上的，就手機(jī)APP來講，映客就比我們上得早。之后我們了解了一下，映客用的是虹軟的方案，就去找虹軟談。但虹軟用的是CPU方案，所有數(shù)據(jù)的讀取和處理都要憑借CPU，之后再返回。對于本來就很緊張的CPU而言，這個方案會有很大問題。最后，我們用了GPU的方案，直接在GPU內(nèi)部進(jìn)行美顏的處理。
最早我們嘗試了多家不同的方案，上線后讓很多主播一個個嘗試，看哪個濾鏡的美顏效果最好。最后通過實驗，換了好幾家的方案之后，我們終于找了一家比較好的。以前我們調(diào)到最好的狀態(tài)，就覺得跟映客差不多了，但后來我們找了一個新的解決方案以后，明顯感覺比虹軟的效果要高一個檔次。
不過，現(xiàn)在我們所用的美顏方案已經(jīng)完全是我們自己開發(fā)的方案了，這個后面也會提到。這個新方案與之前我們所用的那個效果最好的技術(shù)提供商方案，從肉眼上已經(jīng)看不出區(qū)別。
這里還有一個很有意思的事情，我們是做技術(shù)的，自己覺得肉眼沒有區(qū)別。我們換了一款濾鏡之后，一丟出去結(jié)果就立刻真有主播找過來，問我們是不是換濾鏡了，是不是改什么東西了，我要的那個效果沒了，也不知道他們是不是有特異功能。我們是完全看不出來什么區(qū)別的，最后就只能用算法來做對比，將兩個算法擺在一起，用程序去分析紅分量、綠分量等各種分量，以及界面上有膚色的地方究竟有什么區(qū)別。因為我們所有的工程師用肉眼看完，都覺得沒有問題了，只要一丟出去，就立刻有主播找過來，問我們是不是改東西了。
目前來講，我們還是有這個信心的，在美顏這塊我們算有比較明顯的優(yōu)勢。
5、萌顏功能
2016年初FaceU大火的時候，我們就想到了將這個想法插入直播App中。最初的第一個版本僅花費(fèi)了兩天時間就出爐了，用的是蘋果自帶的人臉識別方案，但做出來的效果與FaceU差距很大，原因在于蘋果自帶的人臉識別，抖動非常厲害。即使用戶和手機(jī)都保持靜止，系統(tǒng)每一幀所識別出來的圖像也會不停抖動，導(dǎo)致人頭大小一直變化。
經(jīng)過了解，我們發(fā)現(xiàn)FaceU未采用系統(tǒng)自帶的方案，而是用了SenseTime的方案。于是我們迅速搜尋相關(guān)信息，并積極溝通，購買相關(guān)引擎。
同時我們也在開發(fā)人工智能的相關(guān)功能，例如下面寫著360人工智能研究院，識別的圖片。我們也有針對相關(guān)問題，積極組織工程師團(tuán)隊進(jìn)行攻關(guān)。
不過短期內(nèi)我們不可能立刻做出一套能把SenseTime比下去的方案，因此前期我們用的都是SenseTime的方案。借此解決了幾個問題，一個是人臉識別的問題，識別之后在GPU內(nèi)部進(jìn)行處理，播放的視頻效果就是視頻1這樣的。最終形成的結(jié)果，就是將需要的效果與真實圖像疊加在一起。這個問題我們解決得很快，應(yīng)該是第一個上線這個功能的APP了。
具體細(xì)節(jié)我印象還很深刻，大約2016年初即將過春節(jié)的時候，之前的周末我剛把代碼寫完，第二天立刻找SenseTime去簽合同購買引擎。對方的工程師剛上火車，經(jīng)過協(xié)商，對方在火車上給我們Build版本。由于我們自己春節(jié)也要趕火車，時間非常緊張。到最后，我還是在火車上繼續(xù)把代碼寫完的，然后打包上線這個功能了。當(dāng)時這也確實是搶了一個先機(jī)，算是直播app里第一個上線該功能的，就算到現(xiàn)在來講，有這個功能的App也不是很多。
6、換臉、瘦臉、大眼功能
當(dāng)時我們還做了換臉、瘦臉、大眼這些功能。換臉就是類似下圖這樣的效果，這個功能我們已經(jīng)下線了。原因是用了一段時間之后，我們發(fā)現(xiàn)整個花椒的直播間在晚上的時候，效果會非常驚悚，整個氣氛都不對了。后來這個功能就被下線了。
但是瘦臉和大眼的功能現(xiàn)在還是有的，主播現(xiàn)在用的這個版本就可以選擇瘦臉和大眼，以及美顏、美白、磨皮程度的。
7、K歌/曲庫，音效
當(dāng)時在做K歌功能的時候，我們也遇到了很多問題。比如音效功能。話筒講話會帶有一定的混響或音效，比如大禮堂、大房間、小房間這樣的。當(dāng)時我們找了一些解決方案后就匆匆上線了，實際上有一個問題并未解決，就是實時返聽的功能。上線之后，我們就在攻關(guān)實時返聽的功能，現(xiàn)在看來很簡單，在iOS下面根本就不是問題，只要用AudioUnit就可以達(dá)到三毫秒以下返聽的效果。
但當(dāng)時來說，不拿著K歌軟件嘗試一下，我們完全體會不出返聽效果5毫秒和10毫秒之間差別有多大。根據(jù)我們通常的認(rèn)識，比如打電話，只要差別在一百毫秒之內(nèi)，我們會認(rèn)為它是實時的，基本沒有問題。但在唱歌的時候，連10毫秒的時差都是難以忍受的。唱歌時耳朵所聽到的聲音，和自己發(fā)出的聲音之間相差超過10毫秒，歌手就沒法唱下去了。實際上，iOS系統(tǒng)對這個問題解決得比較好，安卓系統(tǒng)并不是所有的手機(jī)都會支持，而iOS就可以把這個時差控制在5毫秒之內(nèi)，用戶耳朵里聽到的聲音跟自己唱得聲音幾乎是同步的。
后來我們還做了變聲、變調(diào)效果，以及氣氛、音效等，基本都是對照著像全民K歌之類的軟件，把能做的功能全都做上了。
直播底層技術(shù)
關(guān)于直播的底層技術(shù)，我們也做了很多嘗試。
1、降低CPU的消耗
我們做了很多降低CPU消耗的嘗試，包括調(diào)整在GPU里處理的畫面的大小，讓處理的像素少一些。效果非常明顯，最下面那根線就是我們改進(jìn)之后的效果。
之前我們的CPU消耗還是很高的，經(jīng)過處理后一下子就降了下來。這個問題的解決辦法，就是要保證在GPU里，所處理的像素是最少的。因為最終我們要把畫面從GPU里拿出來，放到CPU中進(jìn)行傳輸，只要把這個像素壓縮小了，讀取所消耗的時間也會相應(yīng)減少許多。
2、碼率、幀率、分辨率自適應(yīng)，帶寬自適應(yīng)、崩潰續(xù)推
當(dāng)時我們還做了碼率、幀率、分辨率的自適應(yīng)功能，以及帶寬自適應(yīng)、崩潰續(xù)推等功能。
之前我們遇到畫面崩潰的問題，就在考慮續(xù)推的解決方案。后來發(fā)現(xiàn)，這個問題非常簡單，整套直播體系本來就支持這個功能。原因在于：用戶的網(wǎng)絡(luò)本身就會斷掉，閃斷然后再連上，本身就說明它已經(jīng)具有這個續(xù)推的功能了。網(wǎng)絡(luò)都斷了，又繼續(xù)新建連接。于是我們就做了一個簡單的提示，如果需要續(xù)推，我們會提示用戶剛剛發(fā)生閃退，是否要回到直播間，這就OK了。
3、畫質(zhì)改善/清晰度測試（PSNR／靜態(tài)畫質(zhì)清晰度／動態(tài)清晰度）
我們還做了許多改善畫質(zhì)的工作。一種是用PSNR這個業(yè)內(nèi)比較直截了當(dāng)?shù)姆绞?，但我們同時借鑒了單反相機(jī)評測的方法，用了一些比較標(biāo)準(zhǔn)化的測試。原本是用來評測單反相機(jī)的解析度，后來我們用那個標(biāo)準(zhǔn)，對我們各種各樣的算法和處理進(jìn)行打分。這個功能其實也做了蠻長時間的，應(yīng)該來講效果還是比較明顯的。
四、互動秀場階段
新的嘗試
1、雙人連麥和多人連麥
現(xiàn)在我們新加入了雙人連麥的功能，實際上最近我們還在做多人連麥的功能，昨天才發(fā)了新版。之前我們一直熬夜加班在加這個功能，不過我也不敢保證上線后一定會很好。目前我們做了一些比較激進(jìn)的策略，比如不連麥的時候，我們會切換到成本比較低的線路上。一旦真正開始連麥了，再切換回成本比較高的BPG線路上去，當(dāng)中會發(fā)生各種各樣的切換，主播要切換、嘉賓要切換、觀眾那邊也得切換，只能等上線后再看效果，再看會有什么問題。
這個功能中間還是有很多坑的，因為切換需要CDN廠商的支持，當(dāng)時我們也是找了CDN與我們一同進(jìn)行修改。至于后效如何，也只能等著看了。（LiveVideoStack注——唐賡反饋了低成本連麥策略的運(yùn)行情況：經(jīng)過一個多月上線運(yùn)行，穩(wěn)定性超預(yù)期，沒有發(fā)生需要救火的情況，我們設(shè)計的連麥異常自動補(bǔ)救機(jī)制有效運(yùn)行。同時，明顯降低了成本，用戶連麥活躍度明顯增加，連麥推流流量（BGP流量）卻降低了，直接減少了5成以上費(fèi)用，同時對用戶體驗基本沒有影響，沒有用戶抱怨我們在后臺切換線路導(dǎo)致的短時卡頓，完全達(dá)到了我們的設(shè)計初衷。）
2、2D和3D互動禮物
如今已經(jīng)是后秀場時代，我們必須更多地跟主播進(jìn)行互動，因此我們加了很多東西，包括2D和3D的禮物。然后也嘗試了很多游戲引擎之類的內(nèi)容，實際上熊貓直播也嘗試過，他們加了Unity引擎，不過后來失敗了。我們需要的引擎，其生命周期應(yīng)當(dāng)是與直播間的生命周期接近的，甚至是跟禮物的生命周期接近的，出現(xiàn)禮物包的時候才用，不用的時候就釋放掉。但這與游戲引擎的設(shè)計理念不符，對Unity這樣的3D游戲引擎來講，中途釋放是釋放不干凈的。后來我們對Cocos2D-X也是做了非常多的改造，才比較完美地解決了這個問題，包括各種內(nèi)存泄露、狀態(tài)清理不干凈的問題，當(dāng)然最終效果還需要大家等待一下，我們很快就會上線。
3、多人游戲/PK，語音場控/DJ/主持
比較有意思的功能還有一個，就是主播跟觀眾之間的互動游戲功能。
上面的圖片實際上是截自YY，他們加了語音場控、DJ、主持人的功能，以及多人游戲、PK這些功能，我們也在努力，盡快上線這些功能。
4、多人連麥游戲
最近狼人殺等App就用到了12路甚至15路連麥的技術(shù)，上圖來自于美播，其中的一些思路我們也是可以借鑒的。這些都能讓直播間的玩兒法更豐富起來。
互動秀場的AI應(yīng)用
1、綠幕和FABBY摳像
我們做的綠幕摳像技術(shù)，實際上主播一開始是下面第一張圖的情況，背后是綠色的。當(dāng)他選好背后的背景視頻之后，綠幕就會被替換掉，換成第二張那樣視頻。不過這里有個要求：主播背后必須是一塊綠色的背景。
我們對這個功能并不是很滿意，做完這個功能之后，有一款新的APP出來了，叫做FABBY。它可以在沒有綠幕的情況下，就把人像給摳出來。它們所使用的方案是深度學(xué)習(xí)方案，360研究院也立刻就跟進(jìn)了，上圖是我們做出來一些效果。
2、其他
我們還有很多其他研究，包括手勢識別、場景識別、物體識別、主播自動分類（性感、清純等）、畫質(zhì)監(jiān)控、聊天機(jī)器人等。
手勢識別：在很低的CPU消耗下，系統(tǒng)自動識別出主播的手勢，比如比心。
引入265
簡單說一下265，我們對市場上各種265的解決方案進(jìn)行了測試，結(jié)果發(fā)現(xiàn)確實能帶來非常明顯的帶寬節(jié)省效果。節(jié)省的帶寬高達(dá)40%甚至54%，這個數(shù)字非?？鋸埩?。具體數(shù)字如下：
896*504，265 300k > 264 500k，帶寬節(jié)省大于40%
1280*720，265 500k=264 1100k ，帶寬節(jié)省54%
但是，由于現(xiàn)在H5或者其他的一些分享渠道都必須用到264，我們必須在服務(wù)端進(jìn)行轉(zhuǎn)碼。由于對轉(zhuǎn)碼集群的需求，會有一定的費(fèi)用消耗。此外，金山的這個方案本身也非常貴，因此這個方案整體來說也是有一定成本的，并且還需要CDN廠商的支持，才能將265的內(nèi)容傳遞出去。
因此，我們需要整體做一個權(quán)衡，去考慮損益。不過在目前來看，我們覺得這是未來的一個趨勢，而我們也一定會緊跟這個趨勢。
游戲錄屏
現(xiàn)在我們還推出了游戲錄屏功能，我們所使用的是AIRPLAY的錄屏功能，實際上蘋果建議使用REPLAYKIT，但由于REPLAYKIT會要求游戲廠商本身要提供支持，我們還是采用了AIRPLAY的方案。
這里有個問題：AIRPLAY的方案是蘋果明令禁止的，我們在實現(xiàn)時使用了它的私有API，以企業(yè)發(fā)布的形式發(fā)布了采用AIRPLAY的這個版本。
人頭拾音
這也算是個黑科技，如果觀眾戴上耳機(jī)去聽的話，會覺得主播是真的在耳邊說話。聲音會跟隨主播從左耳慢慢走到右耳，甚至連觸摸耳朵的感覺都能感覺出來，閉上眼睛汗毛都要豎起來了。
更多UGC內(nèi)容
我們認(rèn)為，一個直播平臺想要成功的話，必須要有更多的UGC內(nèi)容。這點(diǎn)快手就做得非常漂亮，我們的app在內(nèi)容的豐富度上跟快手相比差太遠(yuǎn)了，快手上什么都有，有人在展示如何修理iPhone手機(jī)，有人在玩兒飛機(jī)，有人玩兒多肉植物，有人玩兒玉器，各種各樣的內(nèi)容全都有。
而我們的多樣性還相距甚遠(yuǎn)，主要都是妹子唱歌跳舞這些，需要后期等待運(yùn)營人員的改進(jìn)。
關(guān)于分享者
唐賡
唐賡，北京密境和風(fēng)科技有限公司iOS技術(shù)負(fù)責(zé)人，負(fù)責(zé)直播技術(shù)開發(fā)與研究，目前工作集中在主播端功能特性開發(fā)與優(yōu)化。在音視頻多媒體技術(shù)、云計算、系統(tǒng)優(yōu)化方面有多年工作經(jīng)驗。
廣告時間
『LiveVideoStack Meet：后直播時代技術(shù)』系列沙龍來杭州和上海了！
6月17日和6月24日，『LiveVideoStack Meet：后直播時代技術(shù)』將分別在杭州和上海舉行，淘寶直播的研發(fā)負(fù)責(zé)人 陳舉鋒（豐火）、涂圖 CTO 邱彥林、又拍云CTO 黃慧攀、即構(gòu)科技合伙人 林君、vipabc研發(fā)總監(jiān) 董海冰、喜馬拉雅FM音視頻工程師 馬力、滬江CCtalk技術(shù)負(fù)責(zé)人 楊繼珩、愛奇藝技術(shù)經(jīng)理 周志偉將做分享。網(wǎng)易、蝸牛云直播、B站和聲網(wǎng)的講師還在邀請中。
此外，一如既往的直播技術(shù)技能圖譜、LiveVideoStack紀(jì)念胸針、《WebRTC權(quán)威指南》第三版、《H.265/HEVC原理、標(biāo)準(zhǔn)與實現(xiàn)》、小米藍(lán)牙音箱及各種小禮品，還有晚宴和OpenSpace與專家自由討論應(yīng)有盡有。
長按圖片識別二維碼進(jìn)入各報名頁面，搶30張免費(fèi)票
