本文將分享新浪微博短視頻如何提升用戶體驗、降低成本的思路與實踐，包括提升短視頻發佈速度，降低長視頻轉碼時間，通過新的 Codec 減少帶寬成本等。
作者：李成亞來源：新浪微博|2018-08-06 10:50
概覽
我所在的團隊主要負責新浪微博短視頻從客戶端的轉碼上傳到服務端的轉碼存儲的整條服務鏈路。今天主要向大家分享我們團隊在短視頻方面有關視頻編解碼的實踐與探索。
這是一個簡單的交互圖，表示典型的生產者、消費者和服務方之間的關係，他們在平臺中關心的重點也會有所不同。
需要強調的是，我們今天主要討論通過技術手段改進優化服務併爲消費者帶來更加完善的產品體驗，關於用戶內容的部分並不在此次討論的範疇。
簡單總結下平臺中每方關切的重點：
- 生產者關心視頻的發佈速度，也就是用戶通過微博客戶端發佈一段視頻，從點擊發布按鈕開始到其他人能在微博上看到此視頻所需要時間的長短。
- 消費者關心視頻的觀看體驗，例如是否卡頓，流量消耗等。
- 服務方關心平臺的服務質量。
發佈速度
發送流程與關鍵性問題
先來看發佈速度。首先向大家簡單介紹一下用戶通過微博客戶端發送視頻的流程。
客戶端是一個 iOS 或 Android 平臺應用。
首先，在客戶端我們會對視頻做一次壓縮，其目的是縮小視頻體積。
接下來視頻經過轉碼後會被作爲一個整體文件單獨上傳至 Web Server， Web Server 接收後會將視頻上傳到存儲服務，同時在服務端觸發轉碼操作。
此服務端轉碼的目的是：
- 視頻規範化，統一輸出格式，排查視頻錯誤。
- 視頻標記處理，爲視頻添加水印或標識。
- 自動截圖。接下來服務端轉碼後也會把此視頻文件上傳至存儲服務，最後提示用戶視頻發送成功。
我想大家可以很明顯地看出來這裏有三個關鍵性問題：
- 整個視頻發佈是一個串行的過程。意味着一旦其中任何一個環節出現問題都會導致整個操作的失敗。
- 服務端轉碼慢。因爲曾經的服務端轉碼是一次性轉碼，我們爲了減小視頻壓縮的體積使用了一個比較複雜的算法。
- 長視頻發佈的速度非常慢。曾經在微博上發佈一段最長一小時的視頻，其延時可達好幾個小時。
後來我們重寫或者重構了每條鏈路上一些關鍵節點的服務代碼。
關鍵技術優化
下面我來介紹一下幾個關鍵的技術優化點:
（1）在客戶端，我們會將編碼與上傳合併到同一個流程裏，集成了一個監控編碼器的線程以監測編碼器完成 Gop 數據編碼的數量。
一旦此數量累計到一定閥值後會觸發客戶端的上傳操作，客戶端將這部分數據進行單獨分片並上傳至 Web Server，在 Web Server 收到所有分片之後會進行 Merge 操作，最後上傳至存儲服務。
（2）我們在轉碼端集成了一個調度模塊，此模塊會在發佈階段爲視頻做一次低複雜度的編碼以縮短視頻的發佈延遲。
當完成這次低複雜度轉碼後，調度器會進行一次更高複雜度的轉碼，此轉碼完成之後原播放鏈接會被替換，整個操作流程對用戶而言是無感知的。
（3）對長視頻採取分片並進行轉碼。其大概過程是：首先一個輸入的視頻會被分離成音頻軌和視頻軌。
其次依據其 GOP，視頻軌會被切割成不同的分片，一個分片中可能包含多個 GOP。但一個 GOP 不會被分在不同的分片中，以避免最終視頻合併時出現丟幀而導致視頻觀看卡頓的問題。
最終分片完成後，每一片會被調度器分發到不同的轉碼器同時進行轉碼。
此時調度器會開啓一個監聽線程去監聽此視頻所有分片的轉碼任務，一旦調度器監測到最後一個分片已經處理完成便觸發一次 Merge 操作，就把視頻流的所有分片合併成一個視頻，最後再和音頻軌合併爲一個完整的輸出視頻。
總結與結果
上述流程中我們主要做了以下三點優化：
- 客戶端：將編碼與上傳合併爲一個操作。
- 服務端：分等級轉碼。在發佈階段只進行簡單複雜度的快速編碼。
- 對長視頻進行分片並行轉碼。這裏的兩個關鍵點：A：分離音視頻。B：按 GOP 分割視頻流。
通過上述這些優化，我們可以提升視頻平均發佈速度至原來的 3 倍，提升長視頻發佈速度至原來的 10 倍以上，以上就是我們在視頻發佈階段主要進行的一些優化。
觀看體驗
下面我想與大家分享一些關於觀看體驗的優化，分享之前先爲大家介紹一下產品形態與觀看場景：
（1）產品形態
這是目前微博上主流的兩個視頻類產品，左邊是一個信息流中的視頻，其默認播放尺寸比較小而且基本上都以橫屏呈現；右邊是微博於 2017 年初上線的一個新服務“微博故事”，這是一個全屏播放並可添加 AR 特效的視頻產品，以上是微博視頻業務的兩種產品形態。
（2）觀看場景
觀看場景是指用戶會在什麼樣的場景下觀看微博視頻。首先，在網絡環境上可能是 Wi-Fi 或移動網絡；在終端設備上可能是手機、Pad 或 PC；手機又可依據不同的操作系統、屏幕大小、硬件配置等等進行細分。
如果我們只做一些發佈階段的工作，用戶在不同場景下選擇不同產品形態看到的都是同一份文件。這種方案可能在某些特定的場景下能夠帶來比較好的體驗，但是我相信對於大多數場景這種方案的體驗應該都不是最好的，甚至很糟糕。
服務端轉碼細化
第一項優化是在服務端進行轉碼的細化，簡單地說就是從原來的一個輸出變爲多個輸出，這些輸出之間主要的差別大概是以下三個維度：
- 分辨率從低到高。微博視頻服務的分辨率最低是 240P，最高目前是 720P，在未來還可以更高一些。
- 編碼複雜度從簡單編碼到複雜編碼。
- 視頻格式，例如 MP4、HLS 等等。
下發策略優化
我們會在客戶端構建一個定製化的下發策略，根據產品形態與用戶的網絡環境、設備類型、屏幕的尺寸等硬件配置來選擇一個符合此場景需求的編碼複雜度、分辨率、格式等輸出參數。
通常情況下，我們選擇的輸出都是此用戶在此場景下能夠以足夠清晰度播放的較低碼率視頻。
A/B Test
接下來要講的是一種常見方法叫做 A/B Test，大概分爲四個步驟：定義指標、選擇對照組、變更設置、對比結果。
定義指標
詳細說一下定義指標。第一個是首幀播放延遲，簡單說就是從用戶點擊播放按紐到視頻的第一幀畫面播放出來所需要的時間，包括下載時間、解碼時間、渲染時間等等；第二個是播放失敗率。
第三個是有效播放率，這裏我們有兩個和播放數相關的統計指標：總播放量就是隻要此視頻有一幀被成功播放就算一次，有效播放量是指此視頻連續成功播放多長時間，例如三秒鐘、五秒鐘連續的播放。有效播放率就是這兩者的比值。
選擇對照組
關於選擇對照組我們大概有兩種方式：第一種是隨機選擇，就是從所有的微博用戶中隨機抽取 20% 分成兩個對照組。
第二種是按特徵選擇，可以確定用戶具體的某一個特徵，例如是不是大 V 用戶或粉絲數量處於何種量級，甚至可以按照用戶登陸終端設備不同來進行選擇。
變更設置
這裏我們主要在兩方面進行一些區分與調整：第一是編解碼參數，以 X264 具體來說就是 X264 的那些編解碼參數；第二是下發策略，有時候儘管兩個用戶可能處於同一個場景，但我們依然會下發一個不同的視頻並最終看哪個視頻的數據表現更好。
這裏其實還有一些其他的調整，例如是否啓用客戶端的軟編、硬編、或軟解、硬解等等。
對比結果
最後就是對比結果，這裏主要有兩點，第一是前文定義的核心指標變化情況是趨於優還是差，第二是客觀的視頻質量對比；我們也會藉助一些開源的工具來客觀對比視頻本身的指標，例如 PSNR 或者 SSIM，這也是 A/B Test 的主要內容。
需要說明的是，選擇對照組、變更設置、對比結果是不斷迭代的過程，通過不斷的去調整各種設置最終達到優化指標的目的。
上圖是指在 Wi-Fi 環境下微博自動播放的一種策略。既然是自動播放就涉及到一個問題：播放之前需要先下載視頻，那麼需要下載多少比較合適呢？
Wi-Fi 環境下自動播放
方案一：固定長度下載
一開始我們採取的是一種叫做“固定長度下載”的方案。簡而言之就是每個視頻都提前下載一部分固定長度的數據例如 265K。
當時此功能上線之後我們就發現了兩個比較明顯的問題：
第一是視頻下載服務器佔用帶寬有很大的上升。因爲自動播放的功能，當天的播放量已經上升到之前的兩倍多，其中一部分播放量最終回到視頻的下載原站；第二是有部分的視頻依然會出現輕微的卡頓感。
簡單解釋一下這兩個問題的原因，其實這兩個原因都和下載方式不正確有關係。
帶寬佔用飆升是因爲自動下載導致用戶下載得太多，卡頓感是因爲自動下載下的內容還不足以支撐流暢的播放體驗。
關於第二點需要解釋的是：我們知道對於一個視頻文件，比如說 MP4，它的一些 Meta 信息或 Moov 信息是在頭部的，並且此信息的長度與視頻本身的長度相關，也就是說視頻越長這部分的信息提取量越大，所以對於一些短視頻自動下載 256K 可能太多，但對於長視頻下載 256K 又太少。
方案二：固定時間下載
我們想到了一種固定時間下載的方案，簡而言之就是對每個視頻都先計算好一部分例如前三秒鐘的數據大小，我們在服務端轉碼的同時會計算出此視頻包含的 Meta 信息、Moov 信息、前三幀的 MBAT 等加起來有多大。
在用戶瀏覽信息流的同時和這些信息將與播放鏈接一起下發至客戶端。需要進行解釋的是這個三秒是基於我們反覆調整測試最終得出的一個最佳值，可以在明顯消除自動播放卡頓感的同時控制帶寬的佔用。
提高視頻源的質量
之前微博對發佈視頻的壓縮門檻有了一個質的提升，從 480P 提高到了 720P，並且對全部的微博用戶都開放了此權限。我們未來還可能實現 1080P 的上傳，可以看到隨着分辨率的提升對比左右兩個視頻畫面差距十分明顯。
總結
簡單總結一下對於觀看體驗方面的幾項重要優化：
第一是我們依據定製化的下發策略根據用戶場景自動下發最符合此場景的視頻；第二是我們使用 A/B Test 來幫助不斷完善幾項核心指標，從而優化觀看體驗；第三是我們實現了 Wi-Fi 下的自動播放；第四是提升上傳視頻的質量。
服務質量
作爲服務提供方的我們比較關心的問題可以概括成一句話：怎麼既穩定又省錢地提供高質量的短視頻服務？
這句話有兩個關鍵點：穩定、省錢。爲了保證穩定我們做得更多的其實是一些類似於多機房部署等架構方面的工作，在此不再贅述。
降低成本
省錢，是指成本優化方面。在這裏主要有兩個降低成本的思路：
思路一：保持畫質，提高編碼複雜度，降低碼率。
思路一可以簡單理解爲一個用時間換空間的方案。我們知道隨着編解碼器的發展，在其編碼的複雜度越來越高的同時帶寬與碼率是越來越低，同等碼率下視頻質量越來越高。
以 H.265 爲例，官方給出的比較有代表性的數據是 H.265，相對於 H.264 而言其編碼複雜度大概提升至後者的 10 倍，而碼率能夠達到 H.264 的 50%。
如此高的一個編碼成本提升，如果是在客戶端或是服務端進行都是不現實的。於是我們構想了一種新的思路：熱門視頻的極限轉碼。
思路一優化：熱門視頻極限轉碼
- 業務特點
簡單介紹一下，微博具有一個很明顯的熱點+長尾的業務特點，可能每天 TOP2000 或 TOP1000 部分的視頻會佔到當天視頻播放量的 50% 以上，而絕大部分視頻的播放量很低，只能佔 10%～20%。
根據此種業務特點，我們提出了這種只對一部分熱門視頻進行極限轉碼的方案，從而最大程度地節省計算成本，降低帶寬消耗。
- 熱點判斷
如何判斷某個視頻是否爲熱門視頻？我們主要從以下兩個方面：
第一是預判。在其發佈階段，我們根據發佈方的影響力預判其是否爲熱門視頻，在這裏我們並沒有什麼非常複雜的機器學習算法，而是可以簡單理解爲根據用戶的粉絲數作出判斷。
第二是跟蹤。可能有些視頻在發佈階段並沒有被判定爲一個熱門視頻，但是可能因爲某位微博大 V 轉發了他的視頻或者因爲這個視頻本身很有意思從而帶來播放量的爆發性增長。
在這裏我們會有一個程序去統計某個時間段 t 內全站播放量 Top x 的一部分視頻；隨後這部分中還未進行極限轉碼的視頻，會被調度器投放至一個工作隊列中進行極限轉碼。
這裏的一個小細節是我們的統計時間段 t 與統計視頻數量 x 都可根據機羣的工作負載進行動態調整。
如果機羣整體負載較高，我們會把這兩個數值調低以避免熱門視頻的轉碼對正常發佈視頻的轉碼任務造成過多影響；如果機羣整體負載較低，我們就可把這兩個數適當調大以轉碼處理更多低碼率視頻從而降低帶寬成本。
- 方案選擇
關於方案選擇，在這裏我只是提供一些可供選擇的思路，大概是有三種：
第一是更換編解碼器例如 H.265 或 AV1；第二是使用一些機器學習的技術進行場景識別，判斷此視頻的類型，從而優化編碼過程。第三是使用雲服務，業內的一些雲服務提供商都能提供這種高複雜度轉碼能力的服務。
- 意義與影響
通過採用對熱門視頻進行極限轉碼的方案，我們可以實現 20%～40% 的碼率下降；而在目前所有微博視頻播放量中通過這種高複雜度轉碼處理的視頻的佔比可達到一半以上，與此同時日帶寬節省在一百 TB 以上。
思路二：保持畫質，保持編碼複雜程度，降低成本。
思路二是保持畫質、保持編碼複雜度的同時降低成本。上圖是一個比較簡單的視頻轉碼流程，從視頻輸入到解封裝，再到視頻的解碼與處理，經過視頻的編碼最後封裝與合併到輸出。此流程可以說本身已經沒有什麼優化的餘地。
思路二優化：多輸出轉碼
但這裏有一個前提就是其輸出並不是只有一個而是多個。這些輸出之間的差別可能就是分辨率或格式，其他的大部分的參數是一樣的。
所以我們可以複用解碼的一個環節：可以看到上圖的後半段，在視頻流解碼完成之後視頻會被複製出多份，每份會進行單獨的視頻轉碼，緊接着複製出的每一個流會與音頻流合併成一個單獨的輸出，最終通過此方式我們可以同時轉出多個輸出。
- 意義與影響
通過這種方式，我們可實現整體轉碼耗時節省 15% 左右。
降低集羣冗餘度
我們都知道現在很多的互聯網業務都會面臨一個流量明顯變化的過程，例如一天中某個時間段會出現流量的高峯或低谷。
如果希望集羣能夠經受住流量高峯的考驗就需要保持一個比較高的冗餘度，可能需要保持 1.5 甚至 2 倍的冗餘，才能在流量高峯時段保證互聯網服務的穩定進行。
以下是關於此方面我們進行的一些工作：
消除差異
首先，在整個短視頻服務的環節中，整條鏈路由以下四個服務構成：上傳服務、轉碼服務、存儲服務、業務服務。
這些服務所需要的配置、運行環境，甚至實現語言都是不一樣的，而每個服務都有自己的流量高峯與低谷。
這便導致了這樣一個問題：如果按傳統方式，需要每個服務始終保持一個比較高的冗餘度，那麼所有服務加起來整個集羣的冗餘度就會顯得非常高，從而造成一些浪費。
所以我們需要做的是抹除這些服務之間的差異。具體來說是通過最近幾年在後端領域很火的 Docker 技術將包括配置代碼在內的整個運行環境打包成一個鏡像，可以簡單理解爲一個壓縮包。
我們所有的服務依賴的都是這種 Docker 服務，只要在機器上安裝 Docker 軟件就可以隨時啓用所需服務。通過這種方式可以將之前處於高冗餘度下的四個集羣轉變爲一個集羣，此機羣只要保持一定的冗餘度就可完成服務的承載。
定時擴容
上圖是微博大致的每天流量變化趨勢，最右邊那部分是晚 8 點到次日凌晨 0 點的晚高峯，可以說幾乎每天流量都是以這種趨勢變化，晚高峯時段流量會比白天大部分時間段高出 20%～30% 的樣子。
面對這種情況我們會在高峯時段通過一些公有云服務擴充出的一些計算資源承擔這部分高峯流量；當高峯期結束便撤下這些公有云服務以儘可能降低服務的整體成本。
彈性擴容
上圖是之前鹿晗發微博公開戀情的半個小時內，微博一些核心服務的流量變化。可以看到從 12 點的值到最高峯，不到半個小時流量基本翻了 4 倍。
這種量級的上漲是無法通過諸如降級或流量調配等人工干預手段有效應對，這便要求我們的服務器必須具備快速且大批量的彈性擴容能力。
當天我們也是從阿里雲上緊急擴容了超過一千臺的服務器，最終將此熱點事件造成的流量爆炸性增長化險爲夷。
成本優化總結
簡單總結一下我們在成本優化方面做的一些工作：
首先是對熱門視頻進行極限轉碼，通過以最小的計算資源去獲取最大帶寬節省來降低成本。
其次是我們多輸出轉碼，整體上降低一些編碼的成本，隨着發佈的視頻的質量越來越高，多輸出轉碼降低成本所帶來的收益應該會繼續提高。
第三是根據業務的流量變化通過一些彈性擴容的手段來動態調整集羣的規模。
