新浪微博技術分享：微博短視頻服務的優化實踐之路
一、引言
本文來自新浪微博視頻轉碼平臺技術負責人李成亞在LiveVideoStackCon 2017上的分享，由LiveVideoStack整理成文。李成亞分享了微博短視頻如何提高用戶體驗、下降成本的思路與實踐，包括提高短視頻發佈速度，下降長視頻轉碼時間，經過新的Codec減小帶寬成本等。php
本文的短視頻技術跟IM的單聊、羣聊、朋友圈裏的小視頻是相似的東西，文中針對短視頻的相關優化實踐能夠爲您的IM小視頻開發提供必定的參考和借鑑意義，但願對您有用，也感謝分享者李成亞。html
學習交流：算法
- 即時通信開發交流3羣：185926912[推薦]小程序
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》後端
（本文同步發佈於：http://www.52im.net/thread-1843-1-1.html）微信小程序
二、分享者
李成亞：新浪微博視頻轉碼平臺技術負責人。15年加入新浪微博，曾參與微博混合雲體系建設。在互聯網後端服務研發及架構方面有多年的實踐經驗，關注高可用，高併發，雲生態等領域。服務器
三、相關文章
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》微信
四、內容概述
我所在的團隊主要負責微博短視頻從客戶端的轉碼上傳到服務端的轉碼存儲的整條服務鏈路。今天主要向你們分享咱們團隊在短視頻方面有關視頻編解碼的實踐與探索。網絡
這是一個簡單的交互圖，表示典型的生產者、消費者和服務方之間的關係，其在平臺中關心的重點也會有所不一樣，在這裏須要強調的是，咱們今天主要討論經過技術手段改進優化服務併爲消費者帶來更加完善的產品體驗，關於用戶內容的部分並不在這次討論的範疇。架構
簡單總結了一下平臺中每方關切的重點：
生產者關心視頻的發佈速度，也就是用戶經過微博客戶端發佈一段視頻，從點擊發布按鈕開始到其餘人能在微博上看到此視頻所須要時間的長短；
消費者關心視頻的觀看體驗，例如是否卡頓，流量消耗等；
服務方關心平臺的服務質量。
五、發佈速度
5.1 發送流程與關鍵性問題
先來看發佈速度。首先向你們簡單介紹一下用戶經過微博客戶端發送視頻的流程。
客戶端是一個iOS或Android平臺應用：
首先，在客戶端咱們會對視頻作一次壓縮，其目的是縮小視頻體積；
接下來視頻通過轉碼後會被做爲一個總體文件單獨上傳至Web Server；
Web Server接收後會將視頻上傳到存儲服務，同時在服務端觸發轉碼操做。
此服務端轉碼的目的是：
1）視頻規範化，統一輸出格式，排查視頻錯誤；
2）視頻標記處理，爲視頻添加水印或標識；
3）自動截圖。接下來服務端轉碼後也會把此視頻文件上傳至存儲服務，最後提示用戶視頻發送成功。
我想你們能夠很明顯地看出來這裏有三個關鍵性問題：
1）整個視頻發佈是一個串行的過程。意味着一旦其中任何一個環節出現問題都會致使整個操做的失敗；
2）服務端轉碼慢。由於曾經的服務端轉碼是一次性轉碼，咱們爲了減少視頻壓縮的體積使用了一個比較複雜的算法。
3）長視頻發佈的速度很是慢。曾經在微博上發佈一段最長一小時的視頻，其延時可達到好幾個小時。
後來咱們重寫或者重構了每條鏈路上一些關鍵節點的服務代碼。
5.2 關鍵技術優化
下面我來介紹一下幾個關鍵的技術優化點。
1）在客戶端咱們會將編碼與上傳合併到同一個流程裏，咱們在客戶端中集成了一個監控編碼器的線程以監測編碼器完成Gop數據編碼的數量；一旦此數量累計到必定閥值後會觸發客戶端的上傳操做，客戶端將這部分數據進行單獨分片並上傳至Web Server，在Web Server收到全部分片以後會進行Merge操做，最後上傳至存儲服務。
2）咱們在轉碼端集成了一個調度模塊，此模塊會在發佈階段爲視頻作一次低複雜度的編碼以縮短視頻的發佈延遲；當完成此次低複雜度轉碼後調度器會進行一次更高複雜度的轉碼，此轉碼完成以後會原播放連接會被替換，整個操做流程對用戶而言是無感知的。
3）對長視頻採起分片並進行轉碼。其大概過程是：首先一個輸入的視頻會被分離成音頻軌和視頻軌。
其次依據其GOP，視頻軌會被切割成不一樣的分片，一個分片中可能包含多個GOP。但一個GOP不會被分在不一樣的分片中，以免最終視頻合併時出現丟幀而致使視頻觀看卡頓的問題。
最終分片完成後，每一片會被調度器分發到不一樣的轉碼器同時進行轉碼。
此時調度器會開啓一個監聽線程去監聽此視頻全部分片的轉碼任務，一旦調度器監測到最後一個分片已經處理完成便觸發一次Merge操做，把視頻流的全部分片合併成一個視頻，最後再和音頻軌合併爲一個完整的輸出視頻。
5.3 總結與成果
上述流程中咱們主要作了如下三點優化：
1）客戶端：將編碼與上傳合併爲一個操做；
2）服務端：分等級轉碼。在發佈階段只進行簡單複雜度的快速編碼；
3）對長視頻進行分片並行轉碼。這裏的兩個關鍵點：A：分離音視頻。B：按GOP分割視頻流。
經過上述這些優化，咱們能夠提高視頻平均發佈速度至原來的3倍，提高長視頻發佈速度至原來的10倍以上，以上就是咱們在視頻發佈階段主要進行的一些優化。
六、觀看體驗
下面我想與你們分享一些關於觀看體驗的優化，分享以前先爲你們介紹一下產品形態與觀看場景：
1）產品形態
這是目前微博上主流的兩個視頻類產品，左邊是一個信息流中的視頻，其默認播放尺寸比較小並且基本上都以橫屏呈現；右邊是微博於2017年初上線的一個新服務「微博故事」，這是一個全屏播放並可添加AR特效的視頻產品，以上是微博視頻業務的兩種產品形態。
2）觀看場景
觀看場景是指用戶會在什麼樣的場景下觀看微博視頻。首先，在網絡環境上多是Wi-Fi或移動網絡；在終端設備上多是手機、Pad或PC；手機又可依據不一樣的操做系統、屏幕大小、硬件配置等等進行細分。若是咱們只作一些發佈階段的工做，用戶在不一樣場景下選擇不一樣產品形態看到的都是同一份文件。這種方案可能在某些特定的場景下可以帶來比較好的體驗，可是我相信對於大多數場景這種方案的體驗應該都不是最好的，甚至很糟糕。
6.1 服務端轉碼細化
第一項優化是在服務端進行轉碼的細化，簡單地說就是從原來的一個輸出變爲多個輸出，這些輸出之間主要的差異大概是如下三個維度：
1）分辨率從低到高。微博視頻服務的分辨率最低是240P，最高目前是720P，在將來還能夠更高一些；
2）編碼複雜度從簡單編碼到複雜編碼；
3）視頻格式，例如MP四、HLS等等。
6.2 下發策略優化
咱們會在客戶端構建一個定製化的下發策略，根據產品形態與用戶的網絡環境、設備類型、屏幕的尺寸等硬件配置來選擇一個符合此場景需求的編碼複雜度、分辨率、格式等輸出參數。一般狀況下咱們選擇的輸出都是此用戶在此場景下可以以足夠清晰度播放的較低碼率視頻。
6.3 A/B Test
接下來要講的是一種常見方法叫作A/B Test，大概分爲四個步驟：定義指標、選擇對照組、變動設置、對比結果。
1）定義指標
詳細說一下定義指標。第一個是首幀播放延遲，簡單說就是從用戶點擊播放按紐到視頻的第一幀畫面播放出來所須要的時間，包括下載時間、解碼時間、渲染時間等等；第二個是播放失敗率；第三個是有效播放率，這裏咱們有兩個和播放數相關的統計指標：總播放量就是隻要此視頻有一幀被成功播放就算一次，有效播放量是指此視頻連續成功播放多長時間，例如三秒鐘、五秒鐘連續的播放。有效播放率就是這二者的比值。
2）選擇對照組
關於選擇對照組咱們大概有兩種方式：第一種是隨機選擇，就是從全部的微博用戶中隨機抽取20%分紅兩個對照組。第二種是按特徵選擇，能夠肯定用戶具體的某一個特徵，例如是否是大V用戶或粉絲數量處於何種量級，甚至能夠按照用戶登錄終端設備不一樣來進行選擇。
3）變動設置
這裏咱們主要在兩方面進行一些區分與調整：第一是編解碼參數，以 X264具體來講就是X264的那些編解碼參數；第二是下發策略，有時候儘管兩個用戶可能處於同一個場景，但咱們依然會下發一個不一樣的視頻並最終看哪一個視頻的數據表現更好。這裏其實還有一些其餘的調整，例如是否啓用客戶端的軟編、硬編、或軟解、硬解等等。
4）對比結果
最後就是對比結果，這裏主要有兩點，第一是前文定義的核心指標變化狀況是趨於優仍是差，第二是客觀的視頻質量對比；咱們也會藉助一些開源的工具來客觀對比視頻自己的指標，例如PSNR或者SSIM，這也是A/B Test的主要內容。須要說明的是，選擇對照組、變動設置、對比結果是不斷迭代的過程，經過不斷的去調整各類設置最終達到優化指標的目的。
上圖是指在 Wi-Fi 環境下微博自動播放的一種策略。既然是自動播放就涉及到一個問題：播放以前須要先下載視頻，那麼須要下載多少比較合適呢？
6.4 Wi-Fi 環境下自動播放
方案一：固定長度下載
一開始咱們採起的是一種叫作「固定長度下載」的方案。簡而言之就是每一個視頻都提早下載一部分固定長度的數據例如265K，當時此功能上線以後咱們就發現了兩個比較明顯的問題：第一是視頻下載服務器佔用帶寬有很大的上升。由於自動播放的功能，當天的播放量已經上升到以前的兩倍多，其中一部分播放量最終回到視頻的下載原站；第二是有部分的視頻依然會出現輕微的卡頓感。
簡單解釋一下這兩個問題的緣由，其實這兩個緣由都和下載方式不正確有關係。帶寬佔用飆升是由於自動下載致使用戶下載得太多，卡頓感是由於自動下載下的內容還不足以支撐流暢的播放體驗。關於第二點須要進行解釋的是：咱們知道對於一個視頻文件，好比說MP4，它的一些Meta信息或Moov信息是在頭部的，而且此信息的長度與視頻自己的長度相關，也就是說視頻越長這部分的信息提取量越大，因此對於一些短視頻自動下載256K可能太多，但對於長視頻下載256K又太少。
方案二：固定時間下載
咱們想到了一種固定時間下載的方案，簡而言之就是對每一個視頻都先計算好一部分例如前三秒鐘的數據大小，咱們在服務端轉碼的同時會計算出此視頻包含的Meta信息、Moov信息、前三幀的MBAT等加起來有多大；在用戶瀏覽信息流的同時和這些信息將與播放連接一塊兒下發至客戶端。須要進行解釋的是這個3秒是基於咱們反覆調整測試最終得出的一個最佳值，能夠在明顯消除自動播放卡頓感的同時控制帶寬的佔用。
6.5 提升視頻源的質量
以前微博對發佈視頻的壓縮門檻有了一個質的提高，從480P提升到了720P，而且對所有的微博用戶都開放了此權限。咱們將來還可能實現1080P的上傳，能夠看到隨着分辨率的提高對比左右兩個視頻畫面差距十分明顯。
6.6 小結
簡單總結一下對於觀看體驗方面的幾項重要優化：
第一是咱們依據定製化的下發策略根據用戶場景自動下發最符合此場景的視頻；
第二是咱們使用A/B Test來幫助不斷完善幾項核心指標，從而優化觀看體驗；
第三是咱們實現了Wi-Fi下的自動播放；
第四是提高上傳視頻的質量。
七、服務質量
做爲服務提供方的咱們比較關心的問題能夠歸納成一句話：怎麼既穩定又省錢地提供高質量的短視頻服務？這句話有兩個關鍵點：穩定、省錢。爲了保證穩定咱們作得更多的實際上是一些相似於多機房部署等架構方面的工做，在此不用贅述。
7.1 下降成本
省錢，是指成本優化方面。在這裏主要有兩個下降成本的思路：
【思路一：保持畫質，提升編碼複雜度，下降碼率】
思路一能夠簡單理解爲一個用時間換空間的方案。咱們知道隨着編解碼器的發展，在其編碼的複雜度愈來愈高的同時帶寬與碼率是愈來愈低，同等碼率下視頻質量愈來愈高。以H.265爲例，官方給出的比較有表明性的數據是H.265相對於H.264而言其編碼複雜度大概提高至後者的10倍，而碼率可以達到H.264的50%。如此高的一個編碼成本提高，若是是在客戶端或是服務端進行都是不現實的。因而咱們構想了一種新的思路：熱門視頻的極限轉碼。
思路一優化：熱門視頻極限轉碼
（1）業務特色
簡單介紹一下，微博具備一個很明顯的熱點+長尾的業務特色，可能天天TOP2000或TOP1000部分的視頻會佔到當天視頻播放量的50%以上，而絕大部分視頻的播放量很低，只能佔10%～20%。根據此種業務特色，咱們提出了這種只對一部分熱門視頻進行極限轉碼的方案，從而最大程度地節省計算成本，下降帶寬消耗。
（2）熱點判斷
如何判斷某個視頻是否爲熱門視頻？咱們主要從如下兩個方面：第一是預判。在其發佈階段，咱們根據發佈方的影響力預判其是否爲熱門視頻，在這裏咱們並無什麼很是複雜的機器學習算法，而是能夠簡單理解爲根據用戶的粉絲數做出判斷。第二是跟蹤。可能有些視頻在發佈階段並無被斷定爲一個熱門視頻，可是可能由於某位微博大V轉發了他的視頻或者由於這個視頻自己頗有意思從而帶來播放量的爆發性增加。在這裏咱們會有一個程序去統計某個時間段t內全站播放量Top x的一部分視頻；隨後這部分中還未進行極限轉碼的視頻，會被調度器投放至一個工做隊列中進行極限轉碼。這裏的一個小細節是咱們的統計時間段t與統計視頻數量x均可根據機羣的工做負載進行動態調整。若是機羣總體負載較高，咱們會把這兩個數值調低以免熱門視頻的轉碼對正常發佈視頻的轉碼任務形成過多影響；若是機羣總體負載較低，咱們就可把這兩個數適當調大以轉碼處理更多低碼率視頻從而下降帶寬成本。
（3）方案選擇
關於方案選擇，在這裏我只是提供一些可供選擇的思路，大概是有三種：第一是更換編解碼器例如H.265或AV1；第二是使用一些機器學習的技術進行場景識別，判斷此視頻的類型，從而優化編碼過程。第三是使用雲服務，業內的一些雲服務提供商都能提供這種高複雜度轉碼能力的服務。
（4）意義與影響
經過採用對熱門視頻進行極限轉碼的方案，咱們能夠實現20%～40%的碼率降低；而在目前全部微博視頻播放量中經過這種高複雜度轉碼處理的視頻的佔比可達到一半以上，與此同時日帶寬節省在一百TB以上。
【思路二：保持畫質，保持編碼複雜程度，下降成本】
思路二是保持畫質、保持編碼複雜度的同時下降成本。上圖是一個比較簡單的視頻轉碼流程，從視頻輸入到解封裝，再到視頻的解碼與處理，通過視頻的編碼最後封裝與合併到輸出。此流程能夠說自己已經沒有什麼優化的餘地。
思路二優化：多輸出轉碼
但這裏有一個前提就是其輸出並非只有一個而是多個。這些輸出之間的差異可能就是分辨率或格式，其餘的大部分的參數是同樣的。因此咱們能夠複用解碼的一個環節：能夠看到上圖的後半段，在視頻流解碼完成以後視頻會被複製出多份，每份會進行單獨的視頻轉碼，緊接着複製出的每個流會與音頻流合併成一個單獨的輸出，最終經過此方式咱們能夠同時轉出多個輸出。
意義與影響：經過這種方式咱們可實現總體轉碼耗時節省15%左右。
7.2 下降集羣冗餘度
咱們都知道如今不少的互聯網業務都會面臨一個流量明顯變化的過程，例如一天中某個時間段會出現流量的高峯或低谷，若是但願集羣可以經受住流量高峯的考驗就須要保持一個比較高的冗餘度，可能須要保持1.5甚至2倍的冗餘，才能在流量高峯時段保證互聯網服務的穩定進行。
如下是關於此方面咱們進行的一些工做。
消除差別：
首先，在整個短視頻服務的環節中，整條鏈路由如下四個服務構成：上傳服務、轉碼服務、存儲服務、業務服務。這些服務所須要的配置、運行環境，甚至實現語言都是不同的，而每一個服務都有本身的流量高峯與低谷。這便致使了這樣一個問題：若是按傳統方式，須要每一個服務始終保持一個比較高的冗餘度，那麼全部服務加起來整個集羣的冗餘度就會顯得很是高，從而形成一些浪費。因此咱們須要作的是抹除這些服務之間的差別。具體來講是經過最近幾年在後端領域很火的Docker技術將包括配置代碼在內的整個運行環境打包成一個鏡像，能夠簡單理解爲一個壓縮包；咱們全部的服務依賴的都是這種Docker服務，只要在機器上安裝Docker軟件就能夠隨時啓用所需服務。經過這種方式能夠將以前處於高冗餘度下的四個集羣轉變爲一個集羣，此機羣只要保持必定的冗餘度就可完成服務的承載。
定時擴容：
上圖是微博大體的天天流量變化趨勢，最右邊那部分是晚8點到第二天凌晨0點的晚高峯，能夠說幾乎天天流量都是以這種趨勢變化，晚高峯時段流量會比白天大部分時間段高出20%～30%的樣子，面對這種狀況咱們會在高峯時段經過一些公有云服務擴充出的一些計算資源承擔這部分高峯流量；當高峯期結束便撤下這些公有云服務以儘量下降服務的總體成本。
彈性擴容：
上圖是以前鹿晗發微博公開戀情的半個小時內，微博一些核心服務的流量變化。能夠看到從12點的值到最高峯，不到半個小時流量基本翻了4倍。這種量級的上漲是沒法經過諸如降級或流量調配等人工干預手段有效應對，這便要求咱們的服務器必須具有快速且大批量的彈性擴容能力。當天咱們也是從阿里雲上緊急擴容了超過一千臺的服務器，最終將此熱點事件形成的流量爆炸性增加化險爲夷。
7.3 成本優化總結
簡單總結一下咱們在成本優化方面作的一些工做：
首先是對熱門視頻進行極限轉碼，經過以最小的計算資源去獲取最大帶寬節省來下降成本；
其次是咱們多輸出轉碼，總體上下降一些編碼的成本，隨着發佈的視頻的質量愈來愈高，多輸出轉碼下降成本所帶來的收益應該會繼續提升；
第三是根據業務的流量變化經過一些彈性擴容的手段來動態調整集羣的規模。
附錄：更多音視頻開發文章
《即時通信音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通信音視頻開發（九）：實時語音通信的迴音及迴音消除概述》
《即時通信音視頻開發（十）：實時語音通信的迴音消除技術詳解》
《即時通信音視頻開發（十一）：實時語音通信丟包補償技術詳解》
《即時通信音視頻開發（十三）：實時視頻編碼H.264的特色與優點》
《即時通信音視頻開發（十五）：聊聊P2P與實時音視頻的應用狀況》
《即時通信音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通信音視頻開發（十七）：視頻編碼H.26四、VP8的前世此生》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《還在靠「喂喂喂」測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《技術揭祕：支持百萬級粉絲互動的Facebook實時視頻直播》
《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》
《首次披露：快手是如何作到百萬觀衆同場看直播仍能秒開且不卡頓的？》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時視頻直播客戶端技術盤點：Native、HTML五、WebRTC、微信小程序》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-1843-1-1.html）
- 1. 【案例】新浪微博短視頻服務的優化實踐
- 2. 新浪微博短視頻服務的優化實踐
- 3. 微博短視頻服務優化實踐
- 4. Android新浪微博分享
- 5. 新浪微博技術分享：微博實時直播答題的百萬高併發架構實踐
- 6. 【分享】新浪微博我的微博數據集
- 7. 新浪微博視頻下載教程
- 8. 微博MySQL優化之路
- 9. 新浪微博黃波：大數據開源技術框架選型及新浪微博的實踐
- 10. 【分享】新浪微博用戶信息及微博數據集
- 更多相關文章...
- • Hibernate的快照技術 - Hibernate教程
- • XML 相關技術 - XML 教程
- • Spring Cloud 微服務實戰(三) - 服務註冊與發現
- • TiDB 在摩拜單車在線數據業務的應用和實踐
-
每一个你不满意的现在，都有一个你没有努力的曾经。