4月18日QCon性能優(yōu)化面面觀專(zhuān)題會(huì)議上，騰訊研發(fā)總監(jiān)王輝以“十億級(jí)視頻播放技術(shù)優(yōu)化揭秘”為主題，用QQ空間的日均播放量一年內(nèi)從***突破到十億級(jí)所面臨的嚴(yán)峻考驗(yàn)為切入點(diǎn)，為大家分享視頻團(tuán)隊(duì)在視頻組件的整體架構(gòu)、優(yōu)化效果衡量、帶寬優(yōu)化、秒開(kāi)優(yōu)化、緩沖優(yōu)化、成功率優(yōu)化等六個(gè)方面的技術(shù)實(shí)踐。

王輝：大家早上好!我叫王輝，來(lái)自騰訊，從2009年開(kāi)始從事QQ空間技術(shù)研發(fā)，近期主要關(guān)注手機(jī)短視頻、視頻直播、AI智能硬件。很高興能在QCon上與大家一起分享和交流。我今天的話題是“十億級(jí)視頻播放技術(shù)優(yōu)化揭密”。主要介紹我們團(tuán)隊(duì)在去年一年短視頻風(fēng)口上，我們的視頻播放量從5000萬(wàn)到十億級(jí)過(guò)程中的一些技術(shù)實(shí)踐，希望我的介紹能給大家做一些借鑒和參考。

眾所周知，短視頻去年是一個(gè)風(fēng)口，起因是來(lái)自Facebook 2015年Q3的財(cái)報(bào)，財(cái)報(bào)表明在Facebook平臺(tái)上每天有80億次短視頻播放，給Facebook帶來(lái)了強(qiáng)勁的廣告收入，正是這個(gè)數(shù)據(jù)給國(guó)內(nèi)核心大公司和創(chuàng)業(yè)公司帶來(lái)的一些新的突破口。其實(shí)短視頻已經(jīng)不是一個(gè)新的概念，從2006年開(kāi)始國(guó)內(nèi)就有很多公司在做短視頻。隨著Facebook吹起短視頻風(fēng)，去年在短視頻行業(yè)有近百款應(yīng)用出現(xiàn)，中國(guó)網(wǎng)民里面每5個(gè)里面就有1個(gè)是短視頻的用戶，短視頻成為互聯(lián)網(wǎng)的流量入口。

QQ空間也在這個(gè)風(fēng)口中，從2015年11月份的每天5000萬(wàn)視頻播放量，經(jīng)過(guò)一年的耕耘細(xì)作，徒增到2016年12月份的10億量級(jí)，現(xiàn)在還在不斷增長(zhǎng)。

我的演講主要是按照我們產(chǎn)品迭代的幾個(gè)關(guān)鍵步驟展開(kāi)：

首先是快速上線，2015年我也是跟隨著大家的體驗(yàn)快速上線了新短視頻的體驗(yàn)。

其次面臨的是成本問(wèn)題，在做的過(guò)程中做了一些成本的優(yōu)化工作。

然后是體驗(yàn)優(yōu)化。在解決成本問(wèn)題之后，短視頻的觀看體驗(yàn)要做到***。比如說(shuō)視頻的秒開(kāi)、不產(chǎn)生緩沖、不卡、成功率的提升。

快速上線

在開(kāi)始之前，我先介紹一下我們的團(tuán)隊(duì)職責(zé)，我們團(tuán)隊(duì)負(fù)責(zé)手機(jī)QQ和手機(jī)QQ空間兩個(gè)APP，每個(gè)APP有iOS和Android兩個(gè)團(tuán)隊(duì)，一共四個(gè)團(tuán)隊(duì)，四個(gè)團(tuán)隊(duì)負(fù)責(zé)兩個(gè)APP。在這個(gè)項(xiàng)目中，我們四個(gè)團(tuán)隊(duì)要針對(duì)兩個(gè)平臺(tái)實(shí)現(xiàn)四套邏輯，這里的效率是存在一定的問(wèn)題。

關(guān)于短視頻體驗(yàn)，在這之前，我們也只是做到能播放而已，沒(méi)有做很精細(xì)的工作，并且這里的產(chǎn)品觀感體驗(yàn)也不是很一致，也不是很好。

技術(shù)上，之前也只是做很基礎(chǔ)的架構(gòu)，直接由播放器連接服務(wù)器下載數(shù)據(jù)，達(dá)到能播放就可以。之前我們沒(méi)有積極去做這個(gè)事情，導(dǎo)致播放成功率低、失敗原因未知、不支持邊下邊播、緩沖時(shí)間比較長(zhǎng)等問(wèn)題，流量浪費(fèi)也比較嚴(yán)重。在產(chǎn)品上要解決的，是在整個(gè)APP里面把所有產(chǎn)品的體驗(yàn)做到一致，比如說(shuō)每個(gè)功能的觀看體驗(yàn)，視頻浮層的體驗(yàn)，統(tǒng)一觀看體驗(yàn)也為我們項(xiàng)目清除了很多障礙。

而這里的技術(shù)上的要點(diǎn)是非常關(guān)鍵的，***個(gè)是邊下邊播，這是基礎(chǔ)的要求，是為了加快視頻播放速度。第二個(gè)是流量的控制，這么大的平臺(tái)，之前只是做5000萬(wàn)的播放量，如果沒(méi)有流量控制的云策略，可能到后面流量是無(wú)法把控的。第三，剛才講到團(tuán)隊(duì)的現(xiàn)狀，團(tuán)隊(duì)要負(fù)責(zé)兩個(gè)APP，這里要做代碼復(fù)用，不可能再像之前一樣四個(gè)團(tuán)隊(duì)維護(hù)四套代碼，第四，我們支持第三方的視頻源。第五，需要完善監(jiān)控上報(bào)，對(duì)業(yè)務(wù)知根知底。

可以看到，完成核心技術(shù)要點(diǎn)最核心的一點(diǎn)是如何控制視頻的下載，傳統(tǒng)的方式是播放器直接塞播放地址給播放器，它就可以直接播放，這其實(shí)是一個(gè)黑盒。我們?cè)谥虚g加了一個(gè)本地代理，播放器與服務(wù)器的數(shù)據(jù)請(qǐng)求，我們完全可以把控。在這個(gè)過(guò)程中，比如說(shuō)播放器要數(shù)據(jù)時(shí)，可以給它更多的數(shù)據(jù)，這樣能解決它緩沖的問(wèn)題。有了這層代理之后，架構(gòu)也更清晰一點(diǎn)。

基于這樣的架構(gòu)，在MODEL一層做一些業(yè)務(wù)的邏輯，在VideoController這一層做控制視頻的播放和下載。有了下載代理之后，就可以通過(guò)代理管理下載，在APP里面有很多的視頻請(qǐng)求，VideoProxy可以管理這些請(qǐng)求，做流量控制，做預(yù)加載，還可以做優(yōu)先級(jí)調(diào)度和做監(jiān)控上報(bào)，下載邏輯層則主要關(guān)注怎么優(yōu)化服務(wù)器，對(duì)接緩存管理層，同時(shí)我們抽象出了一個(gè)數(shù)據(jù)層，我的數(shù)據(jù)源可以是HTTPDataSource，也可以讀本地，也可以是來(lái)來(lái)自騰訊視頻的數(shù)據(jù)源，也可以是第三方APP的數(shù)據(jù)源，協(xié)議層主要是HTTP、HTTPS、HTTP2的解決。

在VideoController的邏輯里，其實(shí)都可以放到C層來(lái)實(shí)現(xiàn)，這樣安卓和iOS完全可以通用，這一層的邏輯可以在QQ和QQ空間兩個(gè)APP里面使用，相當(dāng)于是我們一套邏輯可以完全復(fù)用，不用再開(kāi)發(fā)四套邏輯，我們團(tuán)隊(duì)的職能也做了相應(yīng)調(diào)整，之前可能是按團(tuán)隊(duì)劃分，四個(gè)團(tuán)隊(duì)負(fù)責(zé)四個(gè)終端，現(xiàn)在可能是按FT的方式劃分做視頻的團(tuán)隊(duì)，iOS做視頻的團(tuán)隊(duì)可能負(fù)責(zé)QQ和QQ空間里的業(yè)務(wù)，安卓也是如此。直播的FT也可以這樣劃分，iOS的負(fù)責(zé)iOS的兩個(gè)APP，安卓的負(fù)責(zé)安卓的兩個(gè)APP，這樣代碼復(fù)用更清晰一點(diǎn)，我的團(tuán)隊(duì)更專(zhuān)注一點(diǎn)。視頻的團(tuán)隊(duì)專(zhuān)注視頻的研發(fā)。

監(jiān)控上報(bào)，肯定是不可缺少的，這是一個(gè)成熟的項(xiàng)目必備的要素。

***， 問(wèn)題定位，老板跟用戶反饋說(shuō)我這個(gè)視頻播不了，要有一套成熟的問(wèn)題定位的方式。

第二， 耗時(shí)統(tǒng)計(jì)，用戶播放這個(gè)視頻花多長(zhǎng)時(shí)間播出來(lái)，這也是要了解到的。

第三， 成功率統(tǒng)計(jì)，外網(wǎng)用戶播放視頻的成功率是多少?還要通過(guò)實(shí)時(shí)報(bào)警，才能及時(shí)知道外網(wǎng)發(fā)生一些故障。

傳統(tǒng)的撈Log方式大家都有，但是這種方式效率太低，需要等用戶上線之后才能撈到Log，Log撈到之后還得花時(shí)間去分析。我們做法的是在關(guān)鍵問(wèn)題上做一些插裝，把每一類(lèi)錯(cuò)誤和每一個(gè)具體的子錯(cuò)誤都能定義出來(lái)，這樣一看錯(cuò)誤碼就知道播放錯(cuò)誤是由什么原因?qū)е碌摹＿€可以把每次播放視頻的鏈路所有關(guān)鍵流水上報(bào)到統(tǒng)計(jì)系統(tǒng)里來(lái)，每一次播放都是一組流水，每一條流水里面就包含了例如***緩沖發(fā)生的Seek，或下載的鏈接是多少，下載的時(shí)間是多少，有了這些流水之后，用戶反饋播放失敗，我首先可以用流水看發(fā)生了什么錯(cuò)誤?錯(cuò)誤在哪一步?每一步信息是什么?幾秒鐘就可以定位到問(wèn)題。

有了這個(gè)數(shù)據(jù)上報(bào)之后，還可以做一些報(bào)表。比如說(shuō)可以做錯(cuò)誤碼的報(bào)表，有了報(bào)表之后就可以跟進(jìn)哪個(gè)錯(cuò)誤是在TOP的，負(fù)責(zé)人是誰(shuí)，原因是什么，都可以看到。

我們也有自己實(shí)時(shí)的曲線，可以看到各項(xiàng)數(shù)據(jù)的情況。在告警方面，基于成功率和失敗率的統(tǒng)計(jì)，進(jìn)行實(shí)時(shí)告警。一出現(xiàn)錯(cuò)誤碼，微信立即可以收到提醒，提醒說(shuō)是什么原因?qū)е逻@次告警，全自動(dòng)。

成本優(yōu)化

上線一個(gè)月之后，一個(gè)壞消息一個(gè)好消息。好消息是播放量漲了4倍，壞消息是帶寬漲了6倍。帶寬優(yōu)化是每個(gè)做視頻的人必須要面臨的問(wèn)題，我們也分析這個(gè)過(guò)程中的原因，發(fā)現(xiàn)因?yàn)楦臑檫呄逻叢ブ笥脩粲^看視頻的意愿比較強(qiáng)，用戶有挑選心理，不是每個(gè)視頻都去看，看了一下之后不喜歡就劃走了，之前下載的那部分其實(shí)是浪費(fèi)的。

如果之前不做限速的話，一點(diǎn)開(kāi)視頻就瘋狂的下數(shù)據(jù)，帶寬有多大就下多少的數(shù)據(jù)，這樣浪費(fèi)很?chē)?yán)重。

我們采取的***個(gè)策略是進(jìn)行流量控制。在高峰期播放到第10秒時(shí)，預(yù)下載N秒數(shù)據(jù)，下載到N秒就停下來(lái)。然后，可以做多級(jí)限速。一開(kāi)始不限速，下載到合適時(shí)機(jī)做1倍碼率限速。高峰期時(shí)預(yù)加載的數(shù)據(jù)會(huì)少一些，防止高峰期時(shí)帶寬占用明顯，這是初級(jí)的策略。最終我們也有碼率切換的策略。這對(duì)用戶的觀看體驗(yàn)影響比較大，這也是之前必備的一個(gè)策略。

上線這個(gè)策略之后，對(duì)帶寬的優(yōu)化還是比較明顯的。在高峰期時(shí)從18：00到凌晨1點(diǎn)帶寬下降25.4%，這個(gè)是我們不斷灰度最終確定的值。這個(gè)值會(huì)影響播放緩沖，因?yàn)閿?shù)據(jù)少的話必定會(huì)卡頓，在卡頓之間和流量之間取了一個(gè)***值，最終是25.4%。

但這樣肯定是不夠的，因?yàn)榱髁繚q的還是很明顯的，我們想到H.265，壓縮率相對(duì)于H.264提升了30%-50%，但它的復(fù)雜度也是呈指數(shù)級(jí)上升。復(fù)雜度導(dǎo)致它的編解碼耗時(shí)更長(zhǎng)，占用資源也更長(zhǎng)。如果把H.265用在客戶端上的話，可能要評(píng)估一些點(diǎn)，比如說(shuō)在編碼上面，現(xiàn)在手機(jī)上沒(méi)有做H.265硬件支持的，相對(duì)于H.264的耗時(shí)3-7倍，之前耗時(shí)可能是10分鐘，而現(xiàn)在可能需要到70分鐘左右。解碼的硬件支持H.265的也很少，耗時(shí)差不多是一樣的。解碼是可行的，你可以采用軟解的方式，這個(gè)帶來(lái)的問(wèn)題是CPU占用非常高，可能之前H.264占20%的CPU，H.265占70%、80%左右，帶來(lái)的問(wèn)題是發(fā)熱和耗電。

結(jié)論，解碼是可行的，但是編碼不用考慮，在移動(dòng)客戶端不可行的情況下，那編碼就要放在后臺(tái)來(lái)做了。

為了解決如何在我們手機(jī)上能夠解碼的問(wèn)題，對(duì)手機(jī)的解碼能力做一次評(píng)估。我在合適的時(shí)機(jī)做一次大規(guī)模的浮點(diǎn)數(shù)運(yùn)算，將數(shù)據(jù)上傳到后臺(tái)服務(wù)器進(jìn)行云適配。如果當(dāng)前的指數(shù)滿足H.265條件的話，可以給你下載H.265視頻給你播放。從而保證軟件解碼柔性可用，針對(duì)視頻源規(guī)格按機(jī)型適配降級(jí)，保證用戶視頻播放體驗(yàn)。

經(jīng)過(guò)我們的統(tǒng)計(jì)，外網(wǎng)上有94%的手機(jī)還是支持H.265解碼的。支持1080P手機(jī)的解碼占46%。

編碼只能在后臺(tái)做，如果在視頻后臺(tái)進(jìn)行全面編碼的話，是不現(xiàn)實(shí)的。因?yàn)榫幋a復(fù)雜度呈指數(shù)級(jí)上升，拿后臺(tái)服務(wù)器進(jìn)行編碼也是不可行的。我們的做法是只用熱點(diǎn)視頻進(jìn)行后臺(tái)轉(zhuǎn)碼，不是所有視頻都去編碼，對(duì)觀看量在TOP N的視頻進(jìn)行編碼，只需要編碼少量的視頻就可以帶來(lái)流量?jī)?yōu)化效果，因?yàn)門(mén)OP N就占了全網(wǎng)80-90%的流量。

因?yàn)闊狳c(diǎn)視頻的熱點(diǎn)轉(zhuǎn)化很快，可能前幾分鐘是熱點(diǎn)，后幾分鐘就不是熱點(diǎn)，因?yàn)樯缃痪W(wǎng)絡(luò)的傳播非常快。我們給后臺(tái)的要求是轉(zhuǎn)碼速度一定要快，在之前沒(méi)有優(yōu)化時(shí)，轉(zhuǎn)一個(gè)10分鐘的視頻要半個(gè)小時(shí)左右。后來(lái)我們做了分布式處理之后，轉(zhuǎn)10分鐘的視頻只用兩三分鐘。一些短視頻最長(zhǎng)5分鐘左右，只要監(jiān)測(cè)到這個(gè)視頻很熱的話，1分鐘之內(nèi)就能轉(zhuǎn)出來(lái)，就是H.265了。

同樣，在H.265編碼器上做了一些優(yōu)化，比如說(shuō)編碼速度和碼率的都會(huì)有提升。

上線H.265優(yōu)化之后，我們的帶寬進(jìn)一步下降，節(jié)省了31%左右。

秒開(kāi)優(yōu)化

帶寬問(wèn)題解決之后，面臨的下一個(gè)問(wèn)題是體驗(yàn)優(yōu)化。用戶最想要的是視頻能立馬播出來(lái)。我們定了一個(gè)秒開(kāi)技術(shù)指標(biāo)，只要這個(gè)視頻從到我的視野范圍，到視頻播出來(lái)之間的耗時(shí)在一秒以?xún)?nèi)。這也是對(duì)標(biāo)Facebook的體驗(yàn)，F(xiàn)acebook一打開(kāi)動(dòng)態(tài)，視頻是能立即播出來(lái)的，不需要等待就能播，這個(gè)體驗(yàn)其實(shí)很順暢。核心的流程主要是三個(gè)步驟：1、客戶端的耗時(shí);2、下載數(shù)據(jù);3、等待播放。

這里主要有兩個(gè)大的耗時(shí)點(diǎn)，***下載視頻數(shù)據(jù)耗時(shí);第二個(gè)是客戶端的耗時(shí)，下載視頻數(shù)據(jù)耗時(shí)的話，主要是下載數(shù)據(jù)量和下載的速度。

這里有一個(gè)很直接的問(wèn)題，播放器需要下載多少數(shù)據(jù)才能播放?我們可以看一下MP4，MP4其實(shí)是一個(gè)比較靈活的容器格式，每個(gè)東西都是用Box表達(dá)的，每個(gè)Box又可以嵌入到另外一個(gè)Box。MP4主要由MOOV和Mdata組成，MOOV是囊括了所有的視頻關(guān)鍵信息，肯定是先把MOOV下載完之后才能找視頻數(shù)據(jù)才能播起來(lái)。不巧的是，在我們外網(wǎng)會(huì)發(fā)現(xiàn)有5%左右用戶上傳的視頻，它的MOOV是在尾部的。后來(lái)也發(fā)現(xiàn)，有很多安卓手機(jī)比如說(shuō)山寨機(jī)，一些攝像頭處理的廠商可能比較偷懶，因?yàn)樗麄冎挥性谀悴杉晷畔⒅蟛拍苤浪械男畔ⅲ赡馨阉械男畔⒎旁谖膊俊?duì)于MP4來(lái)說(shuō)，一開(kāi)始把頭部下載了，下載頭部時(shí)可能找不到這個(gè)MOOV，就猜測(cè)這個(gè)MOOV在尾部，我可能就有一次請(qǐng)求去探測(cè)這個(gè)頭部到底在哪?這個(gè)探測(cè)的話基本做法是去尾部探測(cè)。如果MOOV在其他地方的話，這次播放肯定是失敗的。現(xiàn)在主流的系統(tǒng)都是去尾部進(jìn)行一次探測(cè)。

比如安卓某些手機(jī)是無(wú)法自定義Range，那就需要下載完整個(gè)文件才能播放。我們的處理方式，用戶在后臺(tái)做一次轉(zhuǎn)碼修復(fù)，客戶端采集后做一次轉(zhuǎn)碼修復(fù)。

再看一下Mdata，這是視頻的原數(shù)據(jù)。目前大部分是H.264編碼，H.264通過(guò)真預(yù)測(cè)的方式來(lái)進(jìn)行視頻編碼，這里有一個(gè)GOP概念，也是在直播里面經(jīng)常談的。一般的視頻需要下載歌完整的GOP數(shù)據(jù)才可以播，可以看到在這個(gè)里面需要下載多少數(shù)據(jù)才能播呢?每個(gè)播放器的行為也不一樣。大家可以看到iOS要下載一個(gè)完整的GOP才可以播。像FFmpegBasedPlayer的話我可能只需要關(guān)鍵幀就可以播出來(lái)。安卓是比較尷尬的一個(gè)系統(tǒng)，在6.0級(jí)以下，可能需要5秒視頻數(shù)據(jù)才可以播起來(lái)。如果說(shuō)是需要下載5秒數(shù)據(jù)才可以播起來(lái)的話，那肯定是非常慢的。我們這里的一個(gè)策略會(huì)采用FFmpegBasedPlayer自己來(lái)做解碼，這里要關(guān)注功能性和耗電的問(wèn)題。

解決了Mdata之后，你會(huì)發(fā)現(xiàn)如果我的數(shù)據(jù)在頭部，拿關(guān)鍵信息進(jìn)行播放的話，其實(shí)我播放的數(shù)據(jù)量非常小的。

對(duì)于下載優(yōu)化的話，會(huì)有一個(gè)防盜鏈的請(qǐng)求，通過(guò)HTTP拿到真實(shí)的才可以下載數(shù)據(jù)。在手機(jī)上執(zhí)行HTTP請(qǐng)求是非常耗時(shí)的，這里我們走私有長(zhǎng)連接通道做這個(gè)事情。

關(guān)于優(yōu)化下載鏈路，這里也是談的比較多的，一般也是直接輸出IP地址，利用IP地址做跑馬的策略，兼顧性能的效率，這個(gè)是用的比較多的方式。

進(jìn)一步思考，按照普遍600K碼率的話，我們統(tǒng)計(jì)到現(xiàn)在APP上面下載的平均速度是400K左右，這樣計(jì)算的話，可能在安卓上面播放一個(gè)視頻的話，需要將近0.9秒左右才可以下載到你需要的數(shù)據(jù)。如果碼率再進(jìn)一步提升的話，可能會(huì)更大，這其實(shí)我們也做了一些場(chǎng)景分析，會(huì)發(fā)現(xiàn)我們是社交網(wǎng)站，它有好友動(dòng)態(tài)，視頻在好友動(dòng)態(tài)里播放，或者是在視頻浮層里播放，我們的選擇是預(yù)加載的策略，這也是常見(jiàn)的策略。我們會(huì)在當(dāng)前看的這條動(dòng)態(tài)時(shí)會(huì)預(yù)加載后面視頻的關(guān)鍵信息，比如說(shuō)會(huì)加載頭部信息和需要播放的數(shù)據(jù)，來(lái)進(jìn)行預(yù)加載。比如說(shuō)在播放當(dāng)前視頻時(shí)，我的視頻在加載一定數(shù)據(jù)之后會(huì)加載下一秒預(yù)加載數(shù)據(jù)，這些都可以做到的。

預(yù)加載有一個(gè)問(wèn)題，我們之前踩了一個(gè)坑，可能預(yù)加載視頻時(shí)還是要優(yōu)先圖片的。視頻當(dāng)然重要，但是社交網(wǎng)絡(luò)上的圖片也更重要，可能在預(yù)加載視頻時(shí)會(huì)考慮到圖片的一些任務(wù)，還有視頻封面之類(lèi)。

優(yōu)化效果也是比較明顯，經(jīng)過(guò)剛才幾個(gè)策略，一個(gè)是我們對(duì)頭和播放器的處理，我們對(duì)防盜鏈的處理，還有對(duì)下載鏈路的處理和預(yù)加載，這樣我們的耗時(shí)大幅度減少了，之前是1.8秒降到0.6秒左右。客戶端的性能也是讓人容易忽視的問(wèn)題，發(fā)現(xiàn)有些用戶雖然有視頻的緩存，但是播起來(lái)還是很慢，這其實(shí)是客戶端性能的影響。因?yàn)橐曨l涉及到的BU和流程比較多，在這個(gè)過(guò)程中還要更關(guān)注到客戶端的影響，要分析下客戶端是哪些在搶占你的視頻播放資源，我們之前犯過(guò)一些錯(cuò)誤，md5會(huì)卡住一些流程，或者是HttpParser會(huì)阻止你的任務(wù)，會(huì)導(dǎo)致視頻播放更慢。

在優(yōu)化視頻播放過(guò)程中，我們?cè)?月份也做直播。直播這里面插入個(gè)事情，我們要播放直播的視頻流，是HLS的視頻，在好友動(dòng)態(tài)里面可以觀看直播的內(nèi)容。HLS在安卓上面體驗(yàn)非常差，因?yàn)榘沧?.0之后對(duì)HLS基本沒(méi)有做的優(yōu)化工作，這里每次安卓上播放HLS需要等待6-9秒。分析發(fā)現(xiàn)它的處理也不是很得當(dāng)，因?yàn)榘沧肯到y(tǒng)請(qǐng)求鏈路較長(zhǎng)，串行下載，需要下載3-4片TS才能啟動(dòng)播放，下載3個(gè)分片的話，耗時(shí)就會(huì)很久。之前提到我們這里有代理，有了代理之后做事情方便很多了，通過(guò)里獲取M3U8，解析M3U8里面有哪些文件，可以做并行下載，只讓他下載一次M3U8，這樣下載速度大幅度提升。回到剛才架構(gòu)上，有了下載代理層的話，你可以做HLS的加速和管理，可以加入HLS的視頻源。

HLS緩沖耗時(shí)也是很明顯的，之前需要6秒左右，現(xiàn)在1.6秒左右就可以播起來(lái)。整體從之前的2秒左右現(xiàn)在優(yōu)化到700m秒，80%用戶都可以在1秒內(nèi)播視頻。

還有一個(gè)是用戶比較關(guān)注的問(wèn)題，觀看視頻時(shí)卡，觀看一會(huì)卡了一下，loading數(shù)據(jù)，loading完以后又卡，這個(gè)體驗(yàn)非常差，我們希望所有的視頻都不卡。其實(shí)這有兩個(gè)播放場(chǎng)景，一個(gè)是正常場(chǎng)景，邊下邊看，數(shù)據(jù)在下載。對(duì)于正常場(chǎng)景下載時(shí)會(huì)做一些帶寬調(diào)整，在低速時(shí)會(huì)做切換IP的處理，比如說(shuō)當(dāng)前連通IP的耗時(shí)比較久的話，會(huì)做一些處理，也會(huì)對(duì)網(wǎng)絡(luò)進(jìn)行速度限制。

針對(duì)Seek場(chǎng)景的話，如果用戶拖動(dòng)的話，文件緩存系統(tǒng)是連續(xù)存儲(chǔ)系統(tǒng)的話，必然會(huì)造成拖到這里時(shí)，后面的緩存數(shù)據(jù)是沒(méi)有辦法下載到系統(tǒng)里面來(lái)的。

我們就對(duì)存儲(chǔ)做了一次重構(gòu)，支持文件空洞。會(huì)按照一兆的方式對(duì)文件進(jìn)行碎片劃分，好處是我可以分段存儲(chǔ)，我可以允許邏輯空洞的，拖動(dòng)的話也可以在后面存儲(chǔ)，也不需要數(shù)據(jù)庫(kù)，我可以知道這是從哪個(gè)位置到哪個(gè)位置的存儲(chǔ)。這樣淘汰緩存也高效一點(diǎn)，并可以制定更靈活的緩存策略。這里可以淘汰更低密度的文件，還可以做的事情是對(duì)文件加密。這里產(chǎn)生卡頓的用戶里面，90%是因?yàn)檫M(jìn)行拖動(dòng)，拖動(dòng)之后又沒(méi)有緩存數(shù)據(jù)，所以這里有可能導(dǎo)致發(fā)生緩沖。統(tǒng)計(jì)效果也是比較明顯的，上了分片緩存之后，之前的緩存概率是4.6%左右，***下降到0.48%，基本上看不到發(fā)生緩沖的場(chǎng)景。

成功率優(yōu)化，也是我們比較關(guān)鍵的指標(biāo)。成功率優(yōu)化沒(méi)有捷徑，可能是Case by Case各個(gè)擊破。之前我們進(jìn)行編碼，有幾百個(gè)錯(cuò)誤碼，錯(cuò)誤碼原因進(jìn)行上報(bào)，每次進(jìn)行循環(huán)，一個(gè)個(gè)錯(cuò)誤碼進(jìn)行解決。下載常見(jiàn)的錯(cuò)誤碼，DNS劫持是比較多的，一些網(wǎng)絡(luò)運(yùn)營(yíng)商會(huì)劫持你的請(qǐng)求。

這個(gè)在國(guó)內(nèi)是比較常見(jiàn)的劫持，有的小運(yùn)營(yíng)商按月會(huì)劫持你的視頻內(nèi)容，可能直接污染你的DNS讓你查找不到CDN，這是比較多的，還有一些網(wǎng)絡(luò)不穩(wěn)定的影響導(dǎo)致。更隱藏的會(huì)直接污染你的視頻內(nèi)容，讓你視頻內(nèi)容是錯(cuò)誤的。播放比較多的可能是一些編碼的原因，剛才提到一些手機(jī)采集出來(lái)的視頻在低端手機(jī)上播不出來(lái)，我們會(huì)對(duì)這些視頻進(jìn)行修復(fù)。

邏輯上的問(wèn)題，因?yàn)椴シ牌饔袪顟B(tài)的，可能開(kāi)發(fā)人員比較多，每個(gè)人過(guò)來(lái)加一個(gè)邏輯的話，會(huì)導(dǎo)致播放狀態(tài)出現(xiàn)問(wèn)題。

我們做的播放器錯(cuò)誤解決方法：

HOOK播放器接口與回調(diào)，實(shí)現(xiàn)播放器狀態(tài)機(jī)，監(jiān)控插放器API的調(diào)用是否合法，不合法直接告警或Crash。幫助開(kāi)發(fā)快速定位問(wèn)題，同時(shí)減輕測(cè)試同事的負(fù)擔(dān)，封裝成UI組件，使其它開(kāi)發(fā)不必理解播放器。

最終優(yōu)化的成果是這樣的，下載成功率優(yōu)化前是97.1%，優(yōu)化后是99.9%。播放成功率優(yōu)化前是97.0%，優(yōu)化后是99.9%。***緩沖耗時(shí)優(yōu)化前是1.95s，優(yōu)化后是0.7s。二次緩沖概率優(yōu)化前是4.63%，優(yōu)化后是0.48%。數(shù)據(jù)還是很可觀的。

我的演講基本是這些，歡迎大家關(guān)注我們團(tuán)隊(duì)的公眾賬號(hào)，也會(huì)分享一些技術(shù)文章。

謝謝大家!

提問(wèn)：剛才您提到已經(jīng)開(kāi)始嘗試用265了，能透露一下265你們播放的在整體中占多大的比例?

王輝：現(xiàn)在熱視頻里面80%都是H.265。10億里面會(huì)有70%、80%左右。

提問(wèn)：推進(jìn)的還是挺靠前的。剛才你提到要判斷手機(jī)的H.265能力，用大規(guī)模的浮點(diǎn)運(yùn)算，首先我先了解一下你們用的什么浮點(diǎn)運(yùn)算的Mark?其次，為什么要用浮點(diǎn)運(yùn)算?其實(shí)視頻編解碼里面幾乎全部都是整數(shù)運(yùn)算。

王輝：浮點(diǎn)運(yùn)算能代表你這個(gè)手機(jī)性能，其實(shí)我們是評(píng)估性能的，不是評(píng)估H.265轉(zhuǎn)碼，如果性能達(dá)到的話，解碼也是可以達(dá)到的。

提問(wèn)：如果想針對(duì)解碼做評(píng)估的話，我建議整數(shù)運(yùn)算。你可以確認(rèn)一下，首先視頻編解碼的標(biāo)準(zhǔn)規(guī)定是沒(méi)有浮點(diǎn)運(yùn)算，不同的編解碼時(shí)限可能會(huì)插入少量的浮點(diǎn)運(yùn)算，大部分是整數(shù)運(yùn)算。

王輝：我們初步做的時(shí)候是判斷手機(jī)有沒(méi)有運(yùn)算能力來(lái)做的浮點(diǎn)運(yùn)算判斷。

主持人：感謝各位嘉賓的提問(wèn)，感謝王輝老師給大家?guī)?lái)的講解。