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