新浪微網誌技術分享：微網誌短視訊服務的優化實踐之路

1、引言

本文來自新浪微網誌視訊轉碼平台技術負責人李成亞在LiveVideoStackCon 2017上的分享，由LiveVideoStack整理成文。李成亞分享了微網誌短視訊如何提升使用者體驗、降低成本的思路與實踐，包括提升短視訊釋出速度，降低長視訊轉碼時間，通過新的Codec減少帶寬成本等。

本文的短視訊技術跟IM的單聊、群聊、朋友圈裡的小視訊是類似的東西，文中針對短視訊的相關優化實踐可以為您的IM小視訊開發提供一定的參考和借鑒意義，希望對您有用，也感謝分享者李成亞。

學習交流：

- 即時通訊開發交流3群： 185926912

[推薦]

- 移動端IM開發入門文章：《

新手入門一篇就夠：從零開發移動端IM 》

（本文同步釋出于：

http://www.52im.net/thread-1843-1-1.html

）

2、分享者

李成亞：

新浪微網誌視訊轉碼平台技術負責人。15年加入新浪微網誌，曾參與微網誌混合雲體系建設。在網際網路後端服務研發及架構方面有多年的實踐經驗，關注高可用，高并發，雲生态等領域。

3、相關文章

《

微信團隊分享：微信Android版小視訊編碼填過的那些坑

4、内容概述

我所在的團隊主要負責微網誌短視訊從用戶端的轉碼上傳到服務端的轉碼存儲的整條服務鍊路。今天主要向大家分享我們團隊在短視訊方面有關視訊編解碼的實踐與探索。

這是一個簡單的互動圖，表示典型的生産者、消費者和服務方之間的關系，其在平台中關心的重點也會有所不同，在這裡需要強調的是，我們今天主要讨論通過技術手段改進優化服務并為消費者帶來更加完善的産品體驗，關于使用者内容的部分并不在此次讨論的範疇。

簡單總結了一下平台中每方關切的重點：

生産者關心視訊的釋出速度，也就是使用者通過微部落格戶端釋出一段視訊，從點選釋出按鈕開始到其他人能在微網誌上看到此視訊所需要時間的長短；

消費者關心視訊的觀看體驗，例如是否卡頓，流量消耗等；

服務方關心平台的服務品質。

5、釋出速度

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倍以上，以上就是我們在視訊釋出階段主要進行的一些優化。

6、觀看體驗

下面我想與大家分享一些關于觀看體驗的優化，分享之前先為大家介紹一下産品形态與觀看場景：

1）産品形态

這是目前微網誌上主流的兩個視訊類産品，左邊是一個資訊流中的視訊，其預設播放尺寸比較小而且基本上都以橫屏呈現；右邊是微網誌于2017年初上線的一個新服務“微網誌故事”，這是一個全屏播放并可添加AR特效的視訊産品，以上是微網誌視訊業務的兩種産品形态。

2）觀看場景

觀看場景是指使用者會在什麼樣的場景下觀看微網誌視訊。首先，在網絡環境上可能是Wi-Fi或移動網絡；在終端裝置上可能是手機、Pad或PC；手機又可依據不同的作業系統、螢幕大小、硬體配置等等進行細分。如果我們隻做一些釋出階段的工作，使用者在不同場景下選擇不同産品形态看到的都是同一份檔案。這種方案可能在某些特定的場景下能夠帶來比較好的體驗，但是我相信對于大多數場景這種方案的體驗應該都不是最好的，甚至很糟糕。

6.1 服務端轉碼細化

第一項優化是在服務端進行轉碼的細化，簡單地說就是從原來的一個輸出變為多個輸出，這些輸出之間主要的差别大概是以下三個次元：

1）分辨率從低到高。微網誌視訊服務的分辨率最低是240P，最高目前是720P，在未來還可以更高一些；

2）編碼複雜度從簡單編碼到複雜編碼；

3）視訊格式，例如MP4、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、服務品質

作為服務提供方的我們比較關心的問題可以概括成一句話：怎麼既穩定又省錢地提供高品質的短視訊服務？這句話有兩個關鍵點：穩定、省錢。為了保證穩定我們做得更多的其實是一些類似于多機房部署等架構方面的工作，在此不用贅述。

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.264、VP8的前世今生 實時語音聊天中的音頻處理與編碼壓縮技術簡述 網易視訊雲技術分享：音頻處理與壓縮技術快速入門 學習RFC3550：RTP/RTCP實時傳輸協定基礎知識 基于RTMP資料傳輸協定的實時流媒體技術研究（論文全文） 聲網架構師談實時音視訊雲的實作難點(視訊采訪) 淺談開發實時視訊直播平台的技術要點 還在靠“喂喂喂”測試實時語音通話品質？本文教你科學的評測方法！ 實作延遲低于500毫秒的1080P實時音視訊直播的實踐分享 移動端實時視訊直播技術實踐：如何做到實時秒開、流暢不卡 如何用最簡單的方法測試你的實時音視訊方案 技術揭秘：支援百萬級粉絲互動的Facebook實時視訊直播 簡述實時音視訊聊天中端到端加密（E2EE）的工作原理 移動端實時音視訊直播技術詳解（一）：開篇 移動端實時音視訊直播技術詳解（二）：采集 移動端實時音視訊直播技術詳解（三）：處理 移動端實時音視訊直播技術詳解（四）：編碼和封裝 移動端實時音視訊直播技術詳解（五）：推流和傳輸 移動端實時音視訊直播技術詳解（六）：延遲優化 理論聯系實際：實作一個簡單地基于HTML5的實時視訊直播 IM實時音視訊聊天時的回聲消除技術詳解 淺談實時音視訊直播中直接影響使用者體驗的幾項關鍵技術名額 如何優化傳輸機制來實作實時音視訊的超低延遲？ 首次披露：快手是如何做到百萬觀衆同場看直播仍能秒開且不卡頓的？ Android直播入門實踐：動手搭建一套簡單的直播系統 網易雲信實時視訊直播在TCP資料傳輸層的一些優化思路 實時音視訊聊天技術分享：面向不可靠網絡的抗丢包編解碼器 P2P技術如何将實時視訊直播帶寬降低75%？ 專訪微信視訊技術負責人：微信實時視訊聊天技術的演進 騰訊音視訊實驗室：使用AI黑科技實作超低碼率的高清實時視訊聊天 微信團隊分享：微信每日億次實時音視訊聊天背後的技術解密 近期大熱的實時直播答題系統的實作思路與技術難點分享 福利貼：最全實時音視訊開發要用到的開源工程彙總 七牛雲技術分享：使用QUIC協定實作實時視訊直播0卡頓！ 實時音視訊聊天中超低延遲架構的思考與技術實踐 了解實時音視訊聊天中的延時問題一篇就夠 實時視訊直播用戶端技術盤點：Native、HTML5、WebRTC、微信小程式 寫給小白的實時音視訊技術入門提綱 微信多媒體團隊訪談：音視訊開發的學習、微信的音視訊技術和挑戰等 騰訊技術分享：微信小程式音視訊技術背後的故事 微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視訊技術 新浪微網誌技術分享：微網誌短視訊服務的優化實踐之路 >>  更多同類文章 ……