微云视频转码架构介绍
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. 未來規劃
由于資源有限，我們的轉碼方案只滿足了分享場景的轉碼需求，并沒有完成覆蓋業務的所有場景。上述轉碼方案其實也是屬于預轉碼，并不能保證所有轉碼過的視頻都會被播放。后續我們計劃實現實時轉碼功能，通過用戶播放操作觸發轉碼，這樣能最大化利用機器資源，做到百分百覆蓋云播場景。
公眾號推薦:
總結
以上是生活随笔為你收集整理的微云视频转码架构介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
