十億級視頻播放技術優化揭密

導語：QCon是由InfoQ主辦的全球頂級技術盛會，每一年在倫敦、北京、東京、紐約、聖保羅、上海、舊金山召開。自 2007年 3月份首次舉辦以來，已經有超萬名高級技術人員參加過QCon大會。QCon內容源於實踐並面向社區，演講嘉賓依據熱點話題，面向 5年以上工做經驗的技術團隊負責人、架構師、工程總監、高級開發人員分享技術創新和最佳實踐。

4月18日性能優化面面觀專題會議上，騰訊研發總監王輝以「十億級視頻播放技術優化揭祕」爲主題，用QQ空間的日均播放量一年內從千萬級突破到十億級所面臨的嚴峻考驗爲切入點，爲你們分享視頻團隊在視頻組件的總體架構、優化效果衡量、帶寬優化、秒開優化、緩衝優化、成功率優化等六個方面的技術實踐。

王輝：你們早上好！我叫王輝，來自騰訊，從2009年開始從事QQ空間技術研發，近期主要關注手機短視頻、視頻直播、AI智能硬件。很高興能在QCon上與你們一塊兒分享和交流。我今天的話題是「十億級視頻播放技術優化揭密」。主要介紹咱們團隊在去年一年短視頻風口上，咱們的視頻播放量從5000萬到十億級過程當中的一些技術實踐，但願個人介紹能給你們作一些借鑑和參考。

衆所周知，短視頻去年是一個風口，原由是來自Facebook 2015年Q3的財報，財報代表在Facebook平臺上天天有80億次短視頻播放，給Facebook帶來了強勁的廣告收入，正是這個數據給國內核心大公司和創業公司帶來的一些新的突破口。其實短視頻已經不是一個新的概念，從2006年開始國內就有不少公司在作短視頻。隨着Facebook吹起短視頻風，去年在短視頻行業有近百款應用出現，中國網民裏面每5個裏面就有1個是短視頻的用戶，短視頻成爲互聯網的流量入口。QQ空間也在這個風口中，從2015年11月份的天天5000萬視頻播放量，通過一年的耕耘細做，徒增到2016年12月份的10億量級，如今還在不斷增加。

個人演講主要是按照咱們產品迭代的幾個關鍵步驟展開：

首先是快速上線，2015年我也是跟隨着你們的體驗快速上線了新短視頻的體驗；

其次面臨的是成本問題，在作的過程當中作了一些成本的優化工做；

而後是體驗優化。在解決成本問題以後，短視頻的觀看體驗要作到極致。好比說視頻的秒開、不產生緩衝、不卡、成功率的提高。

快速上線

在開始以前，我先介紹一下咱們的團隊職責，咱們團隊負責手機QQ和手機QQ空間兩個APP，每一個APP有iOS和Android兩個團隊，一共四個團隊，四個團隊負責兩個APP。在這個項目中，咱們四個團隊要針對兩個平臺實現四套邏輯，這裏的效率是存在必定的問題。

關於短視頻體驗，在這以前，咱們也只是作到能播放而已，沒有作很精細的工做，而且這裏的產品觀感體驗也不是很一致，也不是很好。

技術上，以前也只是作很基礎的架構，直接由播放器鏈接服務器下載數據，達到能播放就能夠。以前咱們沒有積極去作這個事情，致使播放成功率低、失敗緣由未知、不支持邊下邊播、緩衝時間比較長等問題，流量浪費也比較嚴重。在產品上要解決的，是在整個APP裏面把全部產品的體驗作到一致，好比說每一個功能的觀看體驗，視頻浮層的體驗，統一觀看體驗也爲咱們項目清除了不少障礙。

而這裏的技術上的要點是很是關鍵的，第一個是邊下邊播，這是基礎的要求，是爲了加快視頻播放速度。第二個是流量的控制，這麼大的平臺，以前只是作5000萬的播放量，若是沒有流量控制的雲策略，可能到後面流量是沒法把控的。第三，剛纔講到團隊的現狀，團隊要負責兩個APP，這裏要作代碼複用，不可能再像以前同樣四個團隊維護四套代碼，第四，咱們支持第三方的視頻源。第五，須要完善監控上報，對業務知根知底。

能夠看到，完成核心技術要點最核心的一點是如何控制視頻的下載，傳統的方式是播放器直接塞播放地址給播放器，它就能夠直接播放，這實際上是一個黑盒。咱們在中間加了一個本地代理，播放器與服務器的數據請求，咱們徹底能夠把控。在這個過程當中，好比說播放器要數據時，能夠給它更多的數據，這樣能解決它緩衝的問題。有了這層代理以後，架構也更清晰一點。

基於這樣的架構，在MODEL一層作一些業務的邏輯，在VideoController這一層作控制視頻的播放和下載。有了下載代理以後，就能夠經過代理管理下載，在APP裏面有不少的視頻請求，VideoProxy能夠管理這些請求，作流量控制，作預加載，還能夠作優先級調度和作監控上報，下載邏輯層則主要關注怎麼優化服務器，對接緩存管理層，同時咱們抽象出了一個數據層，個人數據源能夠是HTTPDataSource，也能夠讀本地，也能夠是來來自騰訊視頻的數據源，也能夠是第三方APP的數據源，協議層主要是HTTP、HTTPS、HTTP2的解決。

在VideoController的邏輯裏，其實均可以放到C層來實現，這樣安卓和iOS徹底能夠通用，這一層的邏輯能夠在QQ和QQ空間兩個APP裏面使用，至關因而咱們一套邏輯能夠徹底複用，不用再開發四套邏輯，咱們團隊的職能也作了相應調整，以前多是按團隊劃分，四個團隊負責四個終端，如今多是按FT的方式劃分作視頻的團隊，iOS作視頻的團隊可能負責QQ和QQ空間裏的業務，安卓也是如此。直播的FT也能夠這樣劃分，iOS的負責iOS的兩個APP，安卓的負責安卓的兩個APP，這樣代碼複用更清晰一點，個人團隊更專一一點。視頻的團隊專一視頻的研發。

監控上報，確定是不可缺乏的，這是一個成熟的項目必備的要素。

1. 問題定位，老闆跟用戶反饋說我這個視頻播不了，要有一套成熟的問題定位的方式；

2. 耗時統計，用戶播放這個視頻花多長時間播出來，這也是要了解到的；

3. 成功率統計，外網用戶播放視頻的成功率是多少？還要經過實時報警，才能及時知道外網發生一些故障。

傳統的撈Log方式你們都有，可是這種方式效率過低，須要等用戶上線以後才能撈到Log，Log撈到以後還得花時間去分析。咱們作法的是在關鍵問題上作一些插裝，把每一類錯誤和每個具體的子錯誤都能定義出來，這樣一看錯誤碼就知道播放錯誤是由什麼緣由致使的。還能夠把每次播放視頻的鏈路全部關鍵流水上報到統計系統裏來，每一次播放都是一組流水，每一條流水裏面就包含了例如首次緩衝發生的Seek，或下載的連接是多少，下載的時間是多少，有了這些流水以後，用戶反饋播放失敗，我首先能夠用流水看發生了什麼錯誤？錯誤在哪一步？每一步信息是什麼？幾秒鐘就能夠定位到問題。

有了這個數據上報以後，還能夠作一些報表。好比說能夠作錯誤碼的報表，有了報表以後就能夠跟進哪一個錯誤是在TOP的，負責人是誰，緣由是什麼，均可以看到。

咱們也有本身實時的曲線，能夠看到各項數據的狀況。在告警方面，基於成功率和失敗率的統計，進行實時告警。一出現錯誤碼，微信當即能夠收到提醒，提醒說是什麼緣由致使此次告警，全自動。

成本優化

上線一個月以後，一個壞消息一個好消息。好消息是播放量漲了4倍，壞消息是帶寬漲了6倍。帶寬優化是每一個作視頻的人必需要面臨的問題，咱們也分析這個過程當中的緣由，發現由於改成邊下邊播以後用戶觀看視頻的意願比較強，用戶有挑選心理，不是每一個視頻都去看，看了一下以後不喜歡就划走了，以前下載的那部分實際上是浪費的。若是以前不作限速的話，一點開視頻就瘋狂的下數據，帶寬有多大就下多少的數據，這樣浪費很嚴重。

咱們採起的第一個策略是進行流量控制。在高峯期播放到第10秒時，預下載N秒數據，下載到N秒就停下來。而後，能夠作多級限速。一開始不限速，下載到合適時機作1倍碼率限速。高峯期時預加載的數據會少一些，防止高峯期時帶寬佔用明顯，這是初級的策略。最終咱們也有碼率切換的策略。這對用戶的觀看體驗影響比較大，這也是以前必備的一個策略。

上線這個策略以後，對帶寬的優化仍是比較明顯的。在高峯期時從18：00到凌晨1點帶寬降低25.4%，這個是咱們不斷灰度最終肯定的值。這個值會影響播放緩衝，由於數據少的話一定會卡頓，在卡頓之間和流量之間取了一個最優值，最終是25.4%.

但這樣確定是不夠的，由於流量漲的仍是很明顯的，咱們想到H.265，壓縮率相對於H.264提高了30%-50%，但它的複雜度也是呈指數級上升。複雜度致使它的編解碼耗時更長，佔用資源也更長。若是把H.265用在客戶端上的話，可能要評估一些點，好比說在編碼上面，如今手機上沒有作H.265硬件支持的，相對於H.264的耗時3-7倍，以前耗時多是10分鐘，而如今可能須要到70分鐘左右。解碼的硬件支持H.265的也不多，耗時差很少是同樣的。解碼是可行的，你能夠採用軟解的方式，這個帶來的問題是CPU佔用很是高，可能以前H.264佔20%的CPU，H.265佔70%、80%左右，帶來的問題是發熱和耗電。

結論，解碼是可行的，可是編碼不用考慮，在移動客戶端不可行的狀況下，那編碼就要放在後臺來作了。

爲了解決如何在咱們手機上可以解碼的問題，對手機的解碼能力作一次評估。我在合適的時機作一次大規模的浮點數運算，將數據上傳到後臺服務器進行雲適配。若是當前的指數知足H.265條件的話，能夠給你下載H.265視頻給你播放。從而保證軟件解碼柔性可用，針對視頻源規格按機型適配降級，保證用戶視頻播放體驗。

通過咱們的統計，外網上有94%的手機仍是支持H.265解碼的。支持1080P手機的解碼佔46%.

編碼只能在後臺作，若是在視頻後臺進行全面編碼的話，是不現實的。由於編碼複雜度呈指數級上升，拿後臺服務器進行編碼也是不可行的。咱們的作法是隻用熱點視頻進行後臺轉碼，不是全部視頻都去編碼，對觀看量在TOP N的視頻進行編碼，只須要編碼少許的視頻就能夠帶來流量優化效果，由於TOP N就佔了全網80-90%的流量。

由於熱點視頻的熱點轉化很快，可能前幾分鐘是熱點，後幾分鐘就不是熱點，由於社交網絡的傳播很是快。咱們給後臺的要求是轉碼速度必定要快，在以前沒有優化時，轉一個10分鐘的視頻要半個小時左右。後來咱們作了分佈式處理以後，轉10分鐘的視頻只用兩三分鐘。一些短視頻最長5分鐘左右，只要監測到這個視頻很熱的話，1分鐘以內就能轉出來，就是H.265了。

一樣，在H.265編碼器上作了一些優化，好比說編碼速度和碼率的都會有提高。

上線H.265優化以後，咱們的帶寬進一步降低，節省了31%左右。

秒開優化

帶寬問題解決以後，面臨的下一個問題是體驗優化。用戶最想要的是視頻能立馬播出來。咱們定了一個秒開技術指標，只要這個視頻從到個人視野範圍，到視頻播出來之間的耗時在一秒之內。這也是對標Facebook的體驗，Facebook一打開動態，視頻是能當即播出來的，不須要等待就能播，這個體驗其實很順暢。核心的流程主要是三個步驟：一、客戶端的耗時；二、下載數據；三、等待播放。

這裏主要有兩個大的耗時點，第一下載視頻數據耗時；第二個是客戶端的耗時，下載視頻數據耗時的話，主要是下載數據量和下載的速度。

這裏有一個很直接的問題，播放器須要下載多少數據才能播放？咱們能夠看一下MP4，MP4實際上是一個比較靈活的容器格式，每一個東西都是用Box表達的，每一個Box又能夠嵌入到另一個Box。MP4主要由MOOV和Mdata組成，MOOV是囊括了全部的視頻關鍵信息，確定是先把MOOV下載完以後才能找視頻數據才能播起來。不巧的是，在咱們外網會發現有5%左右用戶上傳的視頻，它的MOOV是在尾部的。後來也發現，有不少安卓手機好比說山寨機，一些攝像頭處理的廠商可能比較偷懶，由於他們只有在你採集完信息以後才能知道他全部的信息，他可能把全部的信息放在尾部。對於MP4來講，一開始把頭部下載了，下載頭部時可能找不到這個MOOV，就猜想這個MOOV在尾部，我可能就有一次請求去探測這個頭部到底在哪？這個探測的話基本作法是去尾部探測。若是MOOV在其餘地方的話，此次播放確定是失敗的。如今主流的系統都是去尾部進行一次探測。

好比安卓某些手機是沒法自定義Range，那就須要下載完整個文件才能播放。咱們的處理方式，用戶在後臺作一次轉碼修復，客戶端採集後作一次轉碼修復。

再看一下Mdata，這是視頻的原數據。目前大部分是H.264編碼，H.264經過真預測的方式來進行視頻編碼，這裏有一個GOP概念，也是在直播裏面常常談的。通常的視頻須要下載歌完整的GOP數據才能夠播，能夠看到在這個裏面須要下載多少數據才能播呢？每一個播放器的行爲也不同。你們能夠看到iOS要下載一個完整的GOP才能夠播。像FFmpegBasedPlayer的話我可能只須要關鍵幀就能夠播出來。安卓是比較尷尬的一個系統，在6.0級如下，可能須要5秒視頻數據才能夠播起來。若是說是須要下載5秒數據才能夠播起來的話，那確定是很是慢的。咱們這裏的一個策略會採用FFmpegBasedPlayer本身來作解碼，這裏要關注功能性和耗電的問題。

解決了Mdata以後，你會發現若是個人數據在頭部，拿關鍵信息進行播放的話，其實我播放的數據量很是小的。

對於下載優化的話，會有一個防盜鏈的請求，經過HTTP拿到真實的才能夠下載數據。在手機上執行HTTP請求是很是耗時的，這裏咱們走私有長鏈接通道作這個事情。

關於優化下載鏈路，這裏也是談的比較多的，通常也是直接輸出IP地址，利用IP地址作跑馬的策略，兼顧性能的效率，這個是用的比較多的方式。

進一步思考，按照廣泛600K碼率的話，咱們統計到如今APP上面下載的平均速度是400K左右，這樣計算的話，可能在安卓上面播放一個視頻的話，須要將近0.9秒左右才能夠下載到你須要的數據。若是碼率再進一步提高的話，可能會更大，這其實咱們也作了一些場景分析，會發現咱們是社交網站，它有好友動態，視頻在好友動態裏播放，或者是在視頻浮層裏播放，咱們的選擇是預加載的策略，這也是常見的策略。咱們會在當前看的這條動態時會預加載後面視頻的關鍵信息，好比說會加載頭部信息和須要播放的數據，來進行預加載。好比說在播放當前視頻時，個人視頻在加載必定數據以後會加載下一秒預加載數據，這些均可以作到的。

預加載有一個問題，咱們以前踩了一個坑，可能預加載視頻時仍是要優先圖片的。視頻固然重要，可是社交網絡上的圖片也更重要，可能在預加載視頻時會考慮到圖片的一些任務，還有視頻封面之類。

優化效果也是比較明顯，通過剛纔幾個策略，一個是咱們對頭和播放器的處理，咱們對防盜鏈的處理，還有對下載鏈路的處理和預加載，這樣咱們的耗時大幅度減小了，以前是1.8秒降到0.6秒左右。客戶端的性能也是讓人容易忽視的問題，發現有些用戶雖然有視頻的緩存，可是播起來仍是很慢，這實際上是客戶端性能的影響。由於視頻涉及到的BU和流程比較多，在這個過程當中還要更關注到客戶端的影響，要分析下客戶端是哪些在搶佔你的視頻播放資源，咱們以前犯過一些錯誤，md5會卡住一些流程，或者是HttpParser會阻止你的任務，會致使視頻播放更慢。

在優化視頻播放過程當中，咱們在4月份也作直播。直播這裏面插入個事情，咱們要播放直播的視頻流，是HLS的視頻，在好友動態裏面能夠觀看直播的內容。HLS在安卓上面體驗很是差，由於安卓3.0以後對HLS基本沒有作的優化工做，這裏每次安卓上播放HLS須要等待6-9秒。分析發現它的處理也不是很得當，由於安卓系統請求鏈路較長，串行下載，須要下載3-4片TS才能啓動播放，下載3個分片的話，耗時就會好久。以前提到咱們這裏有代理，有了代理以後作事情方便不少了，經過裏獲取M3U8，解析M3U8裏面有哪些文件，能夠作並行下載，只讓他下載一次M3U8，這樣下載速度大幅度提高。回到剛纔架構上，有了下載代理層的話，你能夠作HLS的加速和管理，能夠加入HLS的視頻源。

HLS緩衝耗時也是很明顯的，以前須要6秒左右，如今1.6秒左右就能夠播起來。總體從以前的2秒左右如今優化到700m秒，80%用戶均可以在1秒內播視頻。

還有一個是用戶比較關注的問題，觀看視頻時卡，觀看一會卡了一下，loading數據，loading完之後又卡，這個體驗很是差，咱們但願全部的視頻都不卡。其實這有兩個播放場景，一個是正常場景，邊下邊看，數據在下載。對於正常場景下載時會作一些帶寬調整，在低速時會作切換IP的處理，好比說當前連通IP的耗時比較久的話，會作一些處理，也會對網絡進行速度限制。

針對Seek場景的話，若是用戶拖動的話，文件緩存系統是連續存儲系統的話，必然會形成拖到這裏時，後面的緩存數據是沒有辦法下載到系統裏面來的。

咱們就對存儲作了一次重構，支持文件空洞。會按照一兆的方式對文件進行碎片劃分，好處是我能夠分段存儲，我能夠容許邏輯空洞的，拖動的話也能夠在後面存儲，也不須要數據庫，我能夠知道這是從哪一個位置到哪一個位置的存儲。這樣淘汰緩存也高效一點，並能夠制定更靈活的緩存策略。這裏能夠淘汰更低密度的文件，還能夠作的事情是對文件加密。這裏產生卡頓的用戶裏面，90%是由於進行拖動，拖動以後又沒有緩存數據，因此這裏有可能致使發生緩衝。統計效果也是比較明顯的，上了分片緩存以後，以前的緩存機率是4.6%左右，最後降低到0.48%，基本上看不到發生緩衝的場景。

成功率優化，也是咱們比較關鍵的指標。成功率優化沒有捷徑，多是Case by Case各個擊破。以前咱們進行編碼，有幾百個錯誤碼，錯誤碼緣由進行上報，每次進行循環，一個個錯誤碼進行解決。下載常見的錯誤碼，DNS劫持是比較多的，一些網絡運營商會劫持你的請求。

這個在國內是比較常見的劫持，有的小運營商按月會劫持你的視頻內容，可能直接污染你的DNS讓你查找不到CDN，這是比較多的，還有一些網絡不穩定的影響致使。更隱藏的會直接污染你的視頻內容，讓你視頻內容是錯誤的。播放比較多的多是一些編碼的緣由，剛纔提到一些手機採集出來的視頻在低端手機上播不出來，咱們會對這些視頻進行修復。

邏輯上的問題，由於播放器有狀態的，可能開發人員比較多，每一個人過來加一個邏輯的話，會致使播放狀態出現問題。

咱們作的播放器錯誤解決方法：

HOOK播放器接口與回調，實現播放器狀態機，監控插放器API的調用是否合法，不合法直接告警或Crash。幫助開發快速定位問題，同時減輕測試同事的負擔，封裝成UI組件，使其它開發沒必要理解播放器。

最終優化的成果是這樣的，下載成功率優化前是97.1%，優化後是99.9%。播放成功率優化前是97.0%，優化後是99.9%。首次緩衝耗時優化前是1.95s，優化後是0.7s。二次緩衝機率優化前是4.63%，優化後是0.48%。數據仍是很可觀的。

個人演講基本是這些，歡迎你們關注咱們團隊的公衆帳號，也會分享一些技術文章。

Q&A

問題1：剛纔您提到已經開始嘗試用265了，能透露一下265大家播放的在總體中佔多大的比例？

王輝：如今熱視頻裏面80%都是H.265。10億裏面會有70%、80%左右。

問題2：推動的仍是挺靠前的。剛纔你提到要判斷手機的H.265能力，用大規模的浮點運算，首先我先了解一下大家用的什麼浮點運算的Mark？其次，爲何要用浮點運算？其實視頻編解碼裏面幾乎所有都是整數運算。

王輝：浮點運算能表明你這個手機性能，其實咱們是評估性能的，不是評估H.265轉碼，若是性能達到的話，解碼也是能夠達到的。

問題3：若是想針對解碼作評估的話，我建議整數運算。你能夠確認一下，首先視頻編解碼的標準規定是沒有浮點運算，不一樣的編解碼時限可能會插入少許的浮點運算，大部分是整數運算。

王輝：咱們初步作的時候是判斷手機有沒有運算能力來作的浮點運算判斷。

主持人：感謝各位嘉賓的提問，感謝王輝老師給你們帶來的講解。

相關閱讀

周杰倫讀心術背後的技術實現

點播文件防盜鏈二三事

HLS 視頻點播初探

此文已由做者受權騰訊雲技術社區發佈，轉載請註明原文出處

原文連接：https://cloud.tencent.com/community/article/446586?fromSource=gwzcw.632156.632156.632156

海量技術實踐經驗，盡在騰訊雲社區