在LiveVideoStackCon2018音影片技術大會上，快手音影片技術負責人於冰分享了題為《使用者導向的音影片體驗最佳化》的主題演講，從使用者的角度來去談音影片的體驗最佳化。
大家好，這次分享主要從使用者的角度來去談音影片的體驗最佳化，做技術的公司通常都喜歡從技術角度出發去講問題，如編解碼演算法、AI技術等。但是我們不妨反過來想一下，什麼是使用者最需要的，對使用者而言什麼是真正的好的體驗，這也是快手的一個基本原則。
今天的演講主要分三個部分：
一是移動影片大時代的快手；
二是使用者導向的音影片體驗最佳化；
三是移動音影片技術趨勢探討。
一、移動影片大時代的快手
移動影片大時代已經到來，從CNNIC最新的網際網路發展狀況統計報告可以看到，2015年下半年到現在，移動網際網路接入流量已經漲了5倍，固定寬頻和4G平均下載速率已經達到了21M，21M是什麼樣的概念？就是4K影片用手機看已經沒有太大問題了。現在制約4G影片發展的主要因素就是資費問題，而各個運營商也在解決這個問題，推出大王卡、免流套餐等等，相信這會讓4G的影片消費越來越猛。 
這是快手短影片下載速率分佈的資料圖，和CNNIC的資料差不多。其中遼寧、河北、山東這些省份速度是最快的，可以看出這些省份運營商最佳化的比較好。另外看右側圖，聯通大資料2018年8月份的戶均月消耗流量排行榜資料顯示，快手排名第一，一位使用者一個月要耗掉1.7GB的流量。快手資料顯示，部分使用者一天就要消耗掉1個G的流量。
在這個移動影片大時代背景下，短影片為什麼異軍突起，而不是長影片繼續獨領風騷？這就要分析長影片和短影片之間的巨大區別。
首先，內容攝製方面，長影片通常以頭部PGC內容為主，由專業裝置拍攝、專業人員製作後期，比如由大IP改編的作品。而短影片UGC內容是移動端拍攝，移動端製作，隨時隨地上傳。
第二，長影片通常是橫屏，1080P或者4K的解析度，適合在大螢幕的電視、電腦上觀看。而短影片都是豎屏，540P或者720P的解析度，更適合手機的解析度及使用習慣。
第三，長影片以頭部內容為主，是集中的熱點內容，數量相對較有限但會覆蓋到大量的使用者，通常人們能看到的、喜歡看的電影差別不會特別大。但是短影片內容是非常長尾的，單個影片播放量會相對比較小，不過會有更多影片被消費者看到。
第四，從消費頻次上看，長影片的觀看是中低頻的，需要使用者用固定時間去消費，看一部電影或追劇需要預留大塊、持續的時間，一般只能在週末假期集中消費。但是短影片卻可以隨時隨地刷，卻非常高頻。
第五，從商業模式上看，長影片一般都採用廣告、訂閱或付費等相對成熟的商業模式，而短影片則是採用免費觀看的模式，並在其中擴充多種商業模式如直播打賞、資訊流廣告、電商等。
因此，正是由於短影片在體驗上的諸多優勢，使得更多使用者願意花費更多時間使用快手等短影片app。
那麼快手的總體情況是怎樣的呢？快手現在日活躍使用者已達1.6億，月活超過3億，原創影片總量為80億條，每日影片播放量150億次，每天上傳影片超過1500萬，一年累計使用者點贊數700億次（2018年12月資料）。
快手的使命是“用科技提升每一個人獨特的幸福感”。在快手，每個人都能夠看到更廣闊的世界，也能夠被更廣闊的世界看到，這就要求平臺堅持普惠、去頭部化，不然普通使用者釋出的影片是無法被更多人看到的。
二、使用者導向的音影片體驗最佳化
什麼是使用者導向的思維方式？接下來我們一起了解一下，技術導向與使用者導向思維模式的差異。上邊這張著名的圖來自於《跨越鴻溝（Crossing the Chasm）》這本書，一個技術在處於圖中Early Adopters階段與Early Majority階段中會有很大的鴻溝，要想跨越這個鴻溝是很有挑戰的，首先需要技術本身非常靠譜，其次要非常理解使用者的訴求，能夠滿足大量使用者的剛需。從技術或使用者兩個角度入手，滿足上述要點，都可以取得成功。
首先看一些技術導向的案例，比如搜尋引擎、無人機、谷歌Chrome瀏覽器，都是透過非常強的技術手段實現，並且恰好滿足了使用者的需求，才會獲得成功。代表性公司是Google，以技術洞見帶來的革命性進展推動市場。也有一些待驗證的技術，處於Early Adopters階段，比如3D電視，需要戴上3D眼鏡才能看觀看，使用率很低；VR影片，我買了很多VR的頭顯裝置，但用過一次後放在抽屜裡再沒有拿出來；4K電視也是類似的困境，很多使用者並不能看出4K和1080P的區別。這些技術之所以沒有大規模普及，主要是因為沒有從使用者角度思考問題。
而使用者導向代表性的公司是Apple，其思維方式是從使用者需求出發，做出超出使用者預期的產品和技術。我個人認為，對使用者的理解其實是更有助於跨越鴻溝的。
再舉個音影片領域的例子，十多年前我跟優酷合作做過一次大規模的音樂會線上直播，是業界最早採用H264 FLV分發技術的案例，支援多機位切換，實時回看。雖然該技術方案與今天所採用的主流方案沒什麼不同，但由於web端大型活動直播的頻次低，使用者粘性不高，並未引起多大的市場反響。直到七八年以後，隨著移動直播體驗的普及，相關技術才真正的走入大眾市場，變成爆炸性增長的產品。
移動直播最早是從美國興起的，如2015年上線的Periscope等App，這些產品創新地在直播中加入了點贊、評論、打賞等機制，用互動性增強了使用者粘性；另外由於移動直播可以隨時隨地開播，又提升了主播與使用者互動的頻度。最終透過使用者的體驗創新來實現了變革。
看完直播，再來看下傳統影片點播App，目前多數影音App是類似YouTube、Netflix這樣介面的傳統互動模式，透過分類、搜尋、推薦等形式構成了複雜互動體驗，對於中低頻的影視劇長影片觀看是比較適合的。但是在移動端碎片化消費的時代，類似快手這種操作介面簡潔、主要透過演算法實現個性化推薦的短影片APP，操作更簡便，反而更受使用者歡迎。
快手是一家使用者導向、技術驅動的公司，這是公司的定位。現在快手屬於已跨越鴻溝且處於上升期的階段，主要優勢有三點：
一是使用者場景簡單，短影片、直播兩種形式的內容，透過推薦做個性化分發，十分易於理解。
二是從使用者使用場景出發設定優先順序，這樣技術落地時就會比較穩、比較準。舉例而言，假如你先研發了一項技術，然後再去找技術的落地點，就如同拿了一把錘子（技術）到處去敲礦石（使用者使用場景），很可能會找不到適合的石頭，或者找到的石頭裡邊沒有好東西；但假如我們手上有很多優質翡翠的原石，再去找錘子，即使可能找到的不是最好最先進的錘子，甚至是石器時代的錘子，也能夠敲開藏著翡翠的原石。
第三個優勢是透過資料驗證你的假設，快手使用者行為樣本量大，資料置信度高。演算法好與不好，上線AB試一下便知道，一切用資料說話。
使用者導向也帶來了很大挑戰，技術人員通常喜歡從技術角度出發想問題，但是現在要換位思考，從使用者角度、需求去考慮，反向思維，這是非常難的事，很多技術人員需要經歷一段時間的轉變才能做到。
另外如剛才我們提及的，一把石器時代的錘子，只要能砸開玉石就是一把好錘子，所以解決問題時並不一定需要最先進的技術。具體而言，解決一個很難的技術問題，可以有不同分數的方案。我們團隊很多同學都是成績優秀的學生，喜歡追求90分的方案，投入了大量的時間和資源，卻可能因為演算法、系統複雜度或其他各種各樣的問題，最後遲遲上不了線；而我們很多線上體驗一開始可能只有30分，採用一個非常簡單的方案就能讓你達到60分，為什麼不先去做一個60分的方案呢？
我們的解決方案就是讓研發人員成為產品的深度使用者，自己從使用者角度推敲最佳化。同時做很多的技術儲備，當使用者需求來了，隨時可以拿出來用。如果自己的技術儲備不夠，又十分著急的話，要考慮採用成熟的第三方技術。技術好不好要用實際資料來說話，看使用者是否接受它，而不是盲目上線技術上看起來很牛卻曲高和寡的東西。
舉個實際例子，快手有個很重要的體驗，直播連麥，也就是主播與粉絲實時音影片連線。2016年，很多直播產品上線了3連麥、4連麥，甚至8連麥、16連麥。快手剛上線直播時，產品團隊從使用者的角度做了評估，考慮直接上線影片連麥可能會給使用者帶來社交壓力，因為被連麥的使用者往往不是主播，不是都喜歡露臉。那麼如何最小化使用者開通連麥的壓力？最易接受的形式就是語音連麥，所以我們最先上線的是技術上簡單一些的語音連麥，也有充足時間把體驗最佳化到最好。事實證明使用者接受度也特別高，等使用者完全接受了語音連麥，並且反饋了需要“露臉”的需求，我們才在2017年上線影片連麥；2018年，影片連麥也無法滿足使用者需求了，進一步上線了影片直播PK的功能，直播PK是一個非常複雜的玩法，而此時快手在技術方面已經做足了儲備，迅速上線滿足了使用者的需求。
接下來介紹下快手的音影片技術體系建設歷程，首先是要從使用者場景的痛點出發；第二是端到端的流程打通；第三是做科學化、精細化的流程管理；第四，介紹一下我們是如何抓重點解決若干核心問題的。
對於移動端短影片的體驗，從拍攝到編輯、釋出，到瀏覽、播放，使用者都有不同的訴求。比如拍攝要真實還原，畫質也要優異；編輯要操作順滑，釋出成功率要高；瀏覽要極速載入、播放流暢，清晰度要高，這是理想的情況。但現實情況是拍攝的時很卡頓，很多效能較差的機型幀率不高，解析度又低，有偏色的問題，畫質也參差不齊；編輯釋出響應非常慢，上傳失敗率高；播放的時候有載入慢、播放卡頓、畫質模糊不清楚的問題。這些都是使用者的痛點，所以我們設計的方案都是針對這些痛點來做的。
接下來是移動端直播體驗，其中直播端涉及推流、連麥，觀眾端就是簡單的觀看。理想中的移動端直播，需要清晰流暢、低延時，觀看端要極速載入、清晰流暢。
我們在實際最佳化過程中會遇到很多的挑戰，比如連麥的體驗，使用者一連上就卡，該如何改進？這裡放了一張《火星救援》的圖，Science the shit out of it，我們相信科學的力量。
怎麼樣才叫科學的方法呢，就是要做到可描述，可衡量，可驗證，具體執行下來必須有分析痛點（確認問題）、提出方案（假設）、本地驗證、線上AB、確認收益幾個環節。首先要分析使用者的痛點，產品、研發、運營等各個團隊都會反饋使用者遇到的問題，之後研發團隊會深入實際的使用者案例，提出通用的解決方案，然後要做本地驗證。誰來驗證呢？就是醫生團隊，我們有專門的音影片質量實驗室，他們來驗證我們的方案是否靠譜。為什麼要本地驗證？因為經常有演算法工程師做了一個演算法，自己驗證過覺得非常好，結果上線後大家說沒效果，這就是缺了一個非常重要的本地驗證的環節。因為演算法可能線上上系統沒有被呼叫，或者引數輸出有問題，要想非常精細化地驗證畫質、音質是否有改善，需要專業團隊專業裝置來做。之後才能去做線上做AB測試，透過資料分析QoS和QoE的指標是否改善。QoS是技術指標比如卡頓，QoE更復雜些,如使用者觀看時長有無變化,而影響時長的因素非常多,想要確認QoE收益需要大量獨立的資料實驗。
為了做端到端的體驗最佳化，我們經過兩年的時間逐步構建了快手端到端的音影片技術體系，打通了整個快手的直播短影片的技術棧。首先是主播端，就是內容生產和直播推流，包括了拍攝、編輯、直播推流三個大的SDK，把影片透過檔案或實時流的方式到雲端。其中短影片源站和直播源站都是我們自建的，短影片的源站是做儲存、轉碼、封面抽取，直播源站是做錄製、實時大規模的轉碼，這些都是業界規模最大的。內容分發是多家一線CDN供應商,消費端是我們的播放器SDK,可以做直播和短影片的播放。
各個環節的QoS、QoE資料都會上報到我們的流媒體大資料平臺上，平臺可以做實時多維的日誌分析、監測和報警，任何區域任何運營商有播放、上傳、推流的問題，在5分鐘之內就可以報警。還可以透過深入的資料分析去找出使用者的痛點，上線最佳化方案，做AB測試，驗證我們的最佳化是否有效。
為什麼要端到端打通技術棧？好處很大，舉個色彩還原的例子，從拍攝開始到編輯、壓縮、傳輸，再到解碼重現，在螢幕上繪製出來，這個過程中很多地方都會涉及到色彩空間的轉換、格式的轉換，任何一個地方做錯了，都會導致呈現出來的影片清晰度、色彩有偏差。想解決這個問題就需要從頭到尾梳理清楚，任何環節有問題都需要修改。
接下來分享一些我們重點解決的核心問題。
首先我們需要先看下短影片的業務特點，快手是海量使用者上傳播放影片的平臺，使用者分佈廣、機型分佈廣。其中，相當一部分快手使用者處於偏遠地區，痛點在於移動端拍攝編輯不流暢，低端機型畫質參差不齊，以及移動端上傳失敗率高，清晰度低、流暢度差等問題。我們主要著力解決的就是這四個問題。
1、最佳化移動端的拍攝和編輯
快手內部多個團隊合作打造了一個效能可伸縮的移動端多媒體引擎，從影片的採集、編輯到上傳實現了全流程打通，帶有媒體引擎、圖形引擎、影像引擎、AR引擎（由AI引擎支撐），再向下是底層的硬體Video Encoder/Decoder，以及CPU、GPU、GSP、NPU的支撐。有了這些引擎、硬體的支援，使用者就可以進行短影片的拍攝編輯、視覺特效、魔法表情、影像增強、AR特效等應用，能夠做到高階的手機效果非常好，低端的機型也能夠流暢的處理。由於演算法複雜度可伸縮，低端手機效果可能相對差一點，但是流暢度沒有問題。
2、最佳化拍攝畫質
最佳化拍攝畫質方面，為了改善低端機的畫質，快手開發了自動增強濾鏡，能夠自動調節色彩亮度，處理畫面偏色偏灰的問題，讓拍攝功能不太好的國產手機獲得跟iPhone差媲美的效果。另外一個效果叫暗光增強，是我們跟北大合作的一個演算法，本來是光線很差、一團漆黑的影片，暗光增強最佳化後細節都非常清楚。
3、最佳化上傳體驗
快手擁有自研的KTP協議，在短影片90%的丟包下還可以正常傳輸資料。理論有效頻寬在不同的丟包率下肯定是逐次降低的，例如90%的丟包率下，可用頻寬可能只有10%，但10%中我們還能用到6%；然而用TCP，丟包率降到20%就不行了，所以用TCP是完全不行的。上線AB驗證的結果，可以看到KTP上傳失敗率降低了27%，取消率降低了23%，還是很有效的。
4、最佳化清晰度、流暢度
清晰度流暢度的矛盾大家應該都遇到過，如何解決呢？影片壓的越小越流暢；而保持同樣影片檔案的大小，壓縮比越高，影片就會越清楚。所以最重要的就是智慧壓縮的演算法。短影片不需要一個恆定的位元速率，我們可以針對不同的內容和場景複雜度，輸出不同的位元速率，自動根據內容做適配。如果是非常複雜的場景，我們會把位元速率調高，如果是非常簡單的場景位元速率可以壓得低一些。另外，我們選擇在雲端做非常高複雜度的壓縮，追求極致的壓縮比。
還有什麼手段來最佳化清晰度呢？可以讓系統把不清晰的影片先過濾掉，例如上圖最左邊的圖片系統可判斷大機率是很清楚的，中間的圖片大機率是模糊的，右邊可判斷實際上是鏡頭髒汙監測。很多使用者的手機拍出來的影片不清楚，主要是因為攝像頭不擦，這些我們系統都能檢測出來。
下面介紹直播場景。快手直播的特點是以移動端推流、播放為主，我們也支援PC端的推流，主要是做遊戲直播。還有一個特點是規模大，是世界上最大的直播平臺，場景非常豐富，玩法多樣，吃飯、釣魚、玩個跳舞機都可以隨時隨地直播。這對我們系統的挑戰也非常大，因為使用者並不只是坐在家裡用固定網路直播，移動端推流的網路、位置都是不確定的。
另外直播玩法多種多樣，比如最近的PK特別火。使用者痛點在於，主播端推流卡頓很多，如果主播很卡，所有使用者都會卡，所以主播卡頓是我們要重點解決的問題。
直播有幾個細分的場景，首先是互動直播，就是我們經常說的觀眾和主播之間的實時互動，它的延遲要求是小於5秒，對流暢性要求特別高，對可靠性要求也非常高，對清晰度要求較高。
其次是遊戲直播，對延遲要求更寬鬆一點，為什麼有的主播其實希望延遲高一點？如果遊戲主播延遲很低，主播在遊戲中就暴露了實時位置，容易被遊戲中的敵人伏擊，所以遊戲主播通常希望延遲在10秒以上，這就是基於使用者個性化體驗的需求，技術人員不做產品可能就理解不了。遊戲直播對流暢性、可靠性要求比較高，清晰度則是要求最高的，因為很多遊戲直播是1080P甚至是藍光的體驗。
最後是PK和連麥場景，延遲要求是在400毫秒以內，對流暢性要求高，可靠性要求不高，能夠容忍一定的丟包。主要是保證低延遲，因為延遲一旦高了，相當於沒有實時性，連麥體驗很差；連麥清晰度方面其實可以做得更高，但是為了保證延遲低，清晰度可能會做一些犧牲。
基於上述分析，我們重點最佳化的方向就是直播上行，這個上行是用KTP推流來解決的，把直播流透過UDP協議推到快手源站，這樣在各種弱網下都可以順暢的直播。然後透過多家CDN去做智慧排程和位元速率自適應，讓觀眾端也更流暢。
上圖是最佳化的一個例子，左邊是TCP，右邊是KTP，影片位元速率大概為3-6M，頻寬限制最高5M，丟包率是10%，這時候可以看到TCP會經常卡頓，KTP則非常流暢。
實時連麥的場景是音影片領域工程和演算法裡面挑戰最大的，像Apple的FaceTime，以及微信的實時音視訊通話，對傳輸、編解碼、音訊處理等相關演算法都是要求最高的環節。
首先，傳輸和編解碼要做到延遲低於400毫秒，在400毫秒以內做所有的演算法，要實現20%的丟包無感知。另外直播連麥要實現無縫切換，不能連麥以後讓所有觀眾卡一下，所以要做很多工程的最佳化。
音訊處理也非常複雜，要做噪聲、回聲、增益的控制演算法。例如PK場景中，兩個主播要一起唱歌，就需要支援高音質的K歌，混響、音效等很多方面也要做相應處理。所以這個架構看起來比較簡單，但是裡面有很多非常複雜的演算法。快手的這套體系全是自主研發，沒有使用開源，便於我們根據業務需求深度定製。
無論直播還是短影片，怎麼才能保證線上的體驗最好？我們的大資料系統負責實時分析、監測和智慧排程，這是快手音影片技術棧的一個突出特點：音影片團隊裡面有一個大資料團隊。我們一開始做的是離線分析系統，做由於資料量太大，做一個實驗，需要跑10個小時資料才能出結果，效率特別低。於是我們開發了實時多維監測報警平臺，能夠實時監測線上的資料到底怎麼樣，任何細分地區都可以看到。我們後面還實現了實時多維AB測試，以前做AB測試需跑兩天才能線上上查資料。現在AB測試上了以後，馬上就能線上看結果、繼續做調優。
下一步我們在做的是實時多CDN智慧排程。過去我們做實時多維監測報警，如果半夜有報警過來，我們要人工看是哪個區域CDN有問題，把它切掉，晚上沒法睡覺很痛苦。有了這個系統以後，切量操作或者量級的配比等最佳化區域性卡頓的操作，都可以讓系統自動去做。
另外，我們還做了故障自動歸因，當一個區域影片發生卡頓了，問題在哪，是運營商的原因還是CDN的原因？如果是CDN的原因我們就找CDN去最佳化，如果CDN沒有問題要透過渠道找運營商去最佳化。歸因非常重要，之前都是要人工排查原因，現在用智慧的演算法就能自動找到原因，直接報警給CDN或運營商方面。
三、移動音影片技術趨勢探討
下邊跟大家聊一下我們所關注的未來的趨勢，大家都能看到，AI是未來的一個大方向，AI的演算法在編解碼演算法、智慧影像技術、傳輸和分發演算法、智慧音訊處理上，都會有長足的發展和應用，快手對此也比較關注。
編解碼是一個基礎技術，我們所有的工程最佳化都是圍繞著編解碼在做，編解碼可謂是音影片的核心引擎。
首先，硬體的編解碼會逐步的成熟，硬體速度快、功耗低、密度高，在移動端、直播等領域應用非常廣泛，移動端方面，我們在iOS、Android大量使用硬體編解碼能力，對提升使用者體驗非常有效；在GPU方面，我們在直播上支援Intel和NVIDIA兩家的高密度硬體編解碼方案；快手也在關注FPGA,評估這個方案在效能和速度上的優勢。我們相信硬體編碼無疑會越來越好，但在短影片領域，我們主要還是用軟體去做，因為我們追求的是壓縮比。
後HEVC時代，我們比較關注的是H.266和VVC的國際標準，還有包括AV1、AVS3、XVC在內的下一代的編解碼技術，快手在美國也建立了標準實驗室團隊，也在澳門的會議上中了兩個提案，我們非常關注下一代標準，希望能貢獻我們的力量。
移動端的影片跟標準的通測序列差異是很大的，快手也很關注在這個移動端的影片集裡，如何能夠針對這些影片的特點在這種序列裡面做一些創新的最佳化演算法。
跟AI的結合方面，我們比較看好的是透過AI來做主觀質量評價。現在很多公司用的都是VMAF，VMAF其實是用傳統影像演算法來做feature extraction（特徵提取）、用SVM來做預測。有沒有辦法用深度學習來做特徵提取和預測？可不可以比VMAF更準更符合人的主觀直覺？ 在有了好的主觀評價方法基礎上，影片的前後處理，也就是影片增強用AI實現也會很有收益。
另外就是針對影片的特點，如何精細地做分析，很多做多媒體分析的同學都是從影像角度來分析的，但如果結合影片特徵做內容理解收益會很大，也就是結合做編解碼的同學對影片模型的理解，以及成熟快速的編解碼演算法，可能對影片內容的理解會非常有幫助。
再看一下ROI(region of interest)編碼，透過AI可以代替人眼找到影片中比較重要的、使用者會感興趣區域，利用ROI編碼圈定使用者主要關注的目標，減少資訊量。但我認為這個只能在超低頻寬情況下使用，如果頻寬足夠，影片還是儘量清楚比較好，如果我們把自己認為的一些不重要的細節抹掉了，這些細節對使用者而言可能恰恰是影片的亮點、趣味性所在。因此ROI在網路不佳的極低位元速率條件下，才會有用武之地。
下面是智慧影像技術。影片的拍攝實際上是一個非常大的領域，跟編解碼演算法要做非常多的結合。如果在快手APP裡面做一個普惠的演算法，能夠覆蓋很多的機型，覆蓋非常多的普通使用者，讓計算攝影學這樣高深的技術走向大眾。這其中有一些推動力量，比如Camera2介面，有了Camera2的介面實際上能獲得更多的資訊，包括更豐富的色彩資訊、更廣的亮度資訊，感知空間的深度資訊，在此基礎之上，可以利用更好的演算法替代傳統的ISP。
快手也在構建自己的Software ISP引擎，希望能夠隨著CPU、NPU算力的增加，AI的能力會讓手機越來越強，可以用這些計算資源做很多複雜的東西，比如場景識別、物體識別；比如針對不同場景物體對影像做有針對性的調優；比如可以做以前移動端做不了的Super Resolution，Denoising， Low Light Enhancement。如果這些演算法如果能夠在移動端跑起來，未來對拍攝體驗的改進會非常大。
這兩年4G在進一步普及，原來很多使用者比較擔心流量費用較高，出門會手動關掉4G流量。最近運營商都在推4G免流套餐，讓使用者能夠放心刷影片，我們預計使用者線上的時長會顯著增加。在更多的場景，比如原來沒辦刷影片的地鐵、高鐵、戶外、人員密集的地方現在都可以刷影片，這對我們的要求就是針對不同的細分網路場景做演算法最佳化。
我們現在比較關注的是多位元速率自適應，直播短影片方面都在嘗試，尤其在短影片上的多位元速率自適應業界是沒有嘗試過的，我們有專門的演算法團隊做這個最佳化。還有Google做的QUIC協議，在使用者體驗提升上面會有很明顯收益的，我們也在關注，各個CDN什麼時候會能夠全面支援。
傳輸和分發怎麼與AI結合呢？我們看好智慧流控，其中包括頻寬預測，還有CDN排程，用強化學習等方法做預測。我們更看重這些演算法能否上線，上線的效果怎麼樣。
2019-2020，5G時代將會正式到來，5G會帶來很多基礎性的變化：高頻寬、低延時。更高的頻寬意味著更高的清晰度，它的頻寬會是4G的一百倍，所以4K、8K、VR都不成問題。在未來的時代要做哪些玩法，進行哪些創新，這是留給大家的思考的問題。還有Wi-Fi可能會逐步被取代，很多地區現在就有這樣的趨勢，如果4G資費足夠低，使用者可能就不裝寬頻了。還有就是IoT（Internet of Things），即任何的裝置都有一個IPv6地址，都可以通訊，24x7的錄製和傳輸影片。再者就是實時通話質量預期可以大幅改善，比如現在微信的語音微信的影片還是不能完全替代電話的，5G時代，這些改變都可能發生。
智慧音訊處理。這是快手另外一塊很重要的演算法，我們會做更高音質的回聲消除、噪聲抑制和增益控制，這方面我們有專業的團隊在做。音訊的編碼傳輸需要在實時傳輸和弱網丟包的情況下做很多的最佳化。
我們也在利用AI技術做音訊理解和生成。比如短影片拍攝的一個痛點是給影片的配樂要花很長時間，我們希望演算法能夠透過使用者的影片內容、場景乃至情緒理解，實現自動選取配樂，甚至自動生成配樂。
我的演講內容如上，感謝LiveVideoStack會方的精心組織，這是一年一度音影片技術愛好者的大聚會，也希望今後有更多的同學參與分享音影片最佳化的經驗，謝謝大家！
