1. 背景

微雲日上傳視訊數達到140萬個，每日播放視訊次數達到1000w次，線上播放視訊成為強烈的需求。但是在PC WEB、H5的播放體驗並不好，原因有兩個：

（1）播放元件支援的視訊格式少，僅支援MP4、MOV等H.264編碼的視訊；

（2）部分視訊（特別是UGC視訊）位元速率過大，導致播放卡頓。

所以我們決定對微雲的視訊轉碼，提供流暢的視訊線上播放體驗。

2. 轉碼原理

原視訊存放在架平倉庫，轉碼視訊時需要先下載視訊到本地，再對下載好的視訊轉碼得到新視訊，最後再把新視訊上傳到雲端。簡單的轉碼流程如下：

為了能在各個客戶端上流暢地播放視訊，我們需要把原視訊轉碼成H.264/AAC編碼、低位元速率的MP4視訊。視訊檔案主要由視訊流和音訊流等資訊組成，其中視訊流和音訊流有著不同的編碼格式。轉碼的過程如下圖，先解封視訊，分別提取視訊流和音訊流，把視訊流轉為H.264格式，把音訊流轉為AAC格式，然後再封裝起來得到新視訊。

我們這裡選擇FFmpeg作為視訊轉碼元件。因為FFmpeg是一個成熟的開源、跨平臺元件，支援多種格式的音視訊轉碼，並提供了一套錄製、轉換以及流化音視訊的完整解決方案。

3. 轉碼架構設計

3.1 哪些視訊需要轉碼？

微雲的存量視訊達到40P，如果都轉碼這些視訊，顯然不太現實，也沒有必要，因為存量視訊的點選播放率較低，投入產出比太低。所以我們經過分析，發現使用者一般是分享視訊的場景下，更多的點選播放視訊。好鋼用在刀刃上，花錢花在跟節眼上，在機器資源有限的情況下，所以我們決定對分享的視訊再進行轉碼。

3.2 轉碼後的新視訊存在哪裡？

原視訊轉碼後會產生新視訊，新視訊的存放應該滿足這幾個條件：

（1）使用者不感知。由於是後臺自動轉碼，所以使用者不應該感知到有新視訊的存在，否則會引起使用者誤會，導致使用者投訴或新視訊被刪。

（2）併發上傳視訊不衝突。由於多個視訊在同時轉碼，所以上傳新視訊時相當於併發寫操作，這裡需要做到併發寫無衝突。

（3）下載速度穩定。

經過討論，我們最後選擇了騰訊雲COS儲存系統來存放新視訊。因為新視訊不能存放在原視訊的使用者的目錄下，否則會使用者會感知到；也不能存在公共的FTN賬號上，因為FTN底層做了對寫排隊保護，如果併發上傳過多，容易導致佇列滿而失敗。而COS系統滿足上面三個條件，支援單目錄併發寫，不容易衝突。

3.3 下載、轉碼、上傳操作流水線化

前面提到，轉碼視訊時需要先下載視訊到本地，再對下載好的視訊轉碼得到新視訊，最後再把新視訊上傳到雲端。

舉個例子，假如有A、B兩個視訊需要轉碼。在同步轉碼模式下，下載模組下載完原視訊A的資料後，轉碼模組拿到視訊A的資料開始轉碼，這時候下載模組就空閒，直到上傳模組把視訊上傳到COS、結束視訊A的完整轉碼過程，下載模組才會開始下一個轉碼任務：下載視訊B的資料。在整個轉碼過程中，每個模組都在等待其他兩個模組的操作完成而空閒著，這樣的轉碼效率低下，白白浪費了很多時間。

顯而易見，這三個模組都是後者依賴前者的輸出結果，也就是說，一旦前者輸出結果後，後續的模組的操作和前者就再無關係。根據這個特點，我們在每個模組之前加入佇列，把下載、轉碼、上傳操作非同步化，各個模組之間不再同步等待轉碼結束，而是在完成本模組的任務後，繼續從佇列裡面取下一個任務。這樣就實現了轉碼的流水線化，極大地提高轉碼效率。簡單流程如下：

這裡我們使用Gearman元件來實現佇列功能，Gearman是一個強大的分散式任務管理元件。詳細介紹可以參見Gearman官網，這裡先不展開詳細介紹了。

3.4 總體架構

經過前面的推論，我們設計出了視訊雲播轉碼的總體架構。如下：

（1）由分享場景觸發視訊轉碼，雲播邏輯server把待轉碼視訊放到下載佇列中，等待轉碼。

（2）使用者播放已轉碼視訊時，從公網直連COS邊下邊播，實現雲播功能。

4. 運營部署

目前雲播轉碼模組已經部署到外網環境，其中使用了40臺V8機器來轉碼視訊，目前已hold住業務分享場景的日常轉碼、雲播需求。

5. 未來規劃

由於資源有限，我們的轉碼方案只滿足了分享場景的轉碼需求，並沒有完成覆蓋業務的所有場景。上述轉碼方案其實也是屬於預轉碼，並不能保證所有轉碼過的視訊都會被播放。後續我們計劃實現實時轉碼功能，通過使用者播放操作觸發轉碼，這樣能最大化利用機器資源，做到百分百覆蓋雲播場景。

公眾號推薦: