導讀：視頻轉碼作為媒體處理的核心功能，在對大視頻文件轉碼時，通常需要花費較長時間，為了提升服務質量，我們將重點提升視頻轉碼的速率。

文｜羅微恒

網(wǎng)易云信高級服務端開發(fā)工程師

在媒體內容傳播行業(yè)中，視頻作為信息傳播的載體，其重要性占比越來越高。通常，為了應對不同的播放場景，視頻需要修改封裝容器格式、編碼格式以及分辨率、碼率等媒體流屬性，這些處理的過程我們統(tǒng)稱其為視頻轉碼。

網(wǎng)易云信集網(wǎng)易 21 年 IM 以及音視頻技術，對外提供行業(yè)一流的融合通信云服務。其中，云信的點播服務，基于分布式處理集群和大規(guī)模分發(fā)系統(tǒng)資源，可滿足全終端設備的播放需求，為企業(yè)用戶提供極速穩(wěn)定的視頻上傳、存儲、轉碼、播放和下載等云服務功能。云信的分布式任務處理系統(tǒng)，則承載了其中的媒體處理這一能力，主要功能有音視頻的轉封裝、轉碼、合并、截圖、加密、加減水印等，以及圖像伸縮、圖像增強、音量歸一化等一系列前處理功能。

本次文章將以分片轉碼為主，介紹網(wǎng)易云信在轉碼提速方面的努力與效果提升。

轉碼性能的影響因子與優(yōu)化

常見的視頻轉碼流程，一般如下圖所示：

在轉碼過程中，瓶頸主要在視頻流，因此我們對速度提升的討論主要針對視頻流處理，音頻流處理暫不在考慮范圍內。針對視頻流處理的環(huán)節(jié)，從以下幾個方面展開討論：

• 源視頻：一般源視頻越長，那么編解碼所需時間則越長。

• 封裝與編解碼：對于視頻轉封裝、關鍵幀片段裁剪等不需要解碼編碼的處理，其所需計算量很小，一般耗時在1~2s。若需要重新編解碼，則根據(jù)源視頻、編碼輸出參數(shù)的不同，所耗時間也不同。常見的有編碼格式以及碼率、分辨率、幀率，比如不同編碼算法的壓縮率與計算復雜度不一樣，導致所需耗時也有所不同，舉例來說 AV1 編碼時間就大于 H.264 的編碼時間。目標碼率、分辨率、幀率等參數(shù)越大，通常計算耗時更大。

• 計算資源的水平與垂直伸縮：通用處理器的單核計算能力越強，轉碼耗時肯定越小。利用 GPU 這類更適合圖像計算處理的專用處理器，也有利于降低轉碼耗時。提升轉碼執(zhí)行流的并發(fā)計算度，也有利于降低轉碼耗時。這里的并發(fā)路數(shù)可以是多線程和多進程，多線程指單進程內以多線程的方式提升，多進程則為通過對文件切片后，多進程對多個切片文件計算。

• 集群任務調度：多租戶的云服務系統(tǒng)，通常都是基于租戶間資源分配優(yōu)先級和租戶內轉碼任務優(yōu)先級綜合而設計的調度算法，調度效率主要在以下幾個方面體現(xiàn)：如何用更少的時間調度多的任務，如何用更少的集群資源實現(xiàn)高吞吐量，如何做好優(yōu)先級和防饑餓的權衡設計。

針對上述的影響因素，我們提出以下幾個優(yōu)化方向：提升硬件能力、優(yōu)化編碼、分片轉碼以及提升集群調度效率。

?專用硬件加速?

多媒體處理是典型的計算密集型場景，優(yōu)化多媒體應用程序的整體計算性能至關重要。CPU 是一種通用計算資源，將視頻圖像類運算 offload 到專用硬件上是一種常見的方案。目前，業(yè)內諸如 Intel、NVIDIA、AMD、ARM、TI 等芯片廠商都有相應的多媒體硬件加速方案，提升高碼率、高分辨率等視頻場景的編碼效率。

我們的轉碼系統(tǒng)主要基于 FFmpeg 多媒體處理框架，在 Linux 平臺上支持的廠商方案有諸如 Intel 的 VA-API （Video Acceleration API）和 Nvidia 的 VDPAU （Video Decode and Presentation API for Unix ），同時兩家廠商也支持了相對更私有的 Intel Quick Sync Video 和 NVENC/NVDEC 加速方案。目前我們主要采用了 Intel 核芯顯卡的視頻加速能力，結合 FFmpeg 社區(qū)的 QSV Plugin 和 VAPPI Plugin 兩種方式，針對 AVDecoder、AVFilter、AVEncoder 三個模塊做了硬件加速。硬件加速相關技術，相關廠商和社區(qū)都在持續(xù)優(yōu)化，在我們的后續(xù)系列文章中，我們也會詳細介紹這塊的進一步實踐。

?AMD 大核服務器?

這里主要指搭載了 AMD EPYC 系列處理器的服務器，相對于我們此前線上的服務器，其單核計算力更強，并行計算能力更優(yōu)異。單核計算力的提升讓我們在解碼、前處理、編碼能有整體性的通用提升，而搭載超大核則是讓我們的分片轉碼方案中的單機多進程場景更加如虎添翼，大大避免了媒體數(shù)據(jù)的跨機器IO通信。

?自研 Codec?

NE264/NE265 是網(wǎng)易云信自主研發(fā)的視頻編碼器，在云信的 NERTC、直播點播中都有所應用。除了編碼性能的提升之外，NE264 更重要的技術優(yōu)勢是低帶寬高畫質，其適用于高碼率高清晰度直播場景（如：游戲直播、線上演唱會、產品發(fā)布會等），可以確保人眼主觀畫面質量不變的情況下，平均節(jié)省 20%~30% 的碼率。這里不再展開介紹，有興趣的可以關注文末相關閱讀。

?分片轉碼?

如果說上面的幾種性能優(yōu)化手段是垂直的，那么本節(jié)所說的分片轉碼則是水平的。視頻流本質就是一連串的圖像組成，并以 IDR 幀為邊界劃分成一串 GOP，每個 GOP 就是獨立的一組圖像集。視頻文件的這一內容特點，決定了我們可以參考 MapReduce 的算法思路，將視頻文件切割為多個分片，然后并行地對分片進行轉碼，最后再合并成一個完整的文件。

?任務調度?

除了對單個轉碼計算執(zhí)行流優(yōu)化之外，我們也需要提升集群資源的整體調度效率。在調度算法這塊，調度節(jié)點既要接收任務提交，又要完成任務下發(fā)的關鍵流程，這個任務下發(fā)的算法設計需要做好多租戶分配、任務優(yōu)先級搶占和盡量提升集群資源利用率的多方平衡。

我們設計了兩種任務下發(fā)的機制：

1. Master 節(jié)點 push 任務到計算節(jié)點

2. 計算節(jié)點主動來 Master 節(jié)點 pull 任務

前者的優(yōu)點是實時性更高，缺點則是 Master 對計算節(jié)點的資源視角是一種 snapshot 快照，有些情況下該快照信息的滯后性會導致部分節(jié)點的過載現(xiàn)象。后者的優(yōu)點則是節(jié)點按需取任務來執(zhí)行，不會出現(xiàn)部分節(jié)點過載的現(xiàn)象，同時在任務選擇性這塊的可編程性更加便利，而缺點則是 Master 對全局資源分配的實時力度掌控性不足。

分片轉碼方案實踐

?媒體流程?

媒體處理的簡易流程如下圖所示，主要分四個步驟：分片前轉封裝（按需）、視頻分片、并行轉碼、視頻合并。

?分片流程?

在集群資源充足的情況下，即任務的調度與分發(fā)一般不會有積壓和資源搶占現(xiàn)象，這種情況下視頻流本身的處理計算，一般會消耗整個任務周期 80%-90% 的時間，所以針對這一階段進行優(yōu)化，可以有更高性價比的收益。

提升硬件能力、優(yōu)化編碼這兩個維度是針對提升單個轉碼進程的計算效率，但是單進程能調用的資源有限，對大視頻文件的速率提升也是很有限。因此，在這里我們探討如何采用分布式 MapReduce 的思想，縮短一個轉碼任務所消耗的時間。接下來的章節(jié)將詳細講述實現(xiàn)分片轉碼技術方案。

分片轉碼流程基礎架構如上圖，我們首先介紹以下幾個概念：

• 父任務：類似于 Hadoop 中的 Job，客戶端提交的轉碼 Job，需將其待轉碼的視頻拆分成多個小分片；

• 子任務：類似于 Hadoop 中的 Task，將多個小分片包裝成可以獨立調度和執(zhí)行的 Task 子任務；

• 父 Worker：執(zhí)行父任務的計算節(jié)點；

• 子 Worker：執(zhí)行子任務的計算節(jié)點。

分片轉碼的主要流程：

Dispatch center 給 worker0 派發(fā)一個轉碼 job，worker0 根據(jù)總開關、job 配置、視頻文件大小等策略判斷是否進行分片轉碼；

如果確定進行分片轉碼，則進行分成 n 片；

包裝成 n 個轉碼Task提交給 Dispatch center；

Dispatch center 將這 n 個轉碼子任務調度給符合要求的 n 個 worker；

worker1~n 轉碼完成后，給 worker0 發(fā)送回調；

worker0 分別從 n 個 worker 上下載轉碼后的分片視頻，待所有分片轉碼完成，將轉碼后的分片合并在一起；

發(fā)送回調給 client。

?子任務調度?

在調度系統(tǒng)中，每個用戶的任務隊列是獨立的，并分別設置任務限額。當 Dispatch center接收到計算節(jié)點的 fetch job 請求時，調度線程先從多個用戶隊列中，選出已使用限額比例（比較簡單的算法模型可以是，已調度任務數(shù)量/用戶總限額）最小的用戶隊列，然后從隊列頭部取出一個符合該計算節(jié)點條件的子任務返回。子任務調度和普通任務調度在調度優(yōu)先級、節(jié)點選擇上有所不同，需要單獨設計，這里我們簡單介紹一下。

• 子任務優(yōu)先級

  子任務不需要在各自用戶隊列里重新排隊，子任務調度的目標是希望可以第一時間被調度到。該父任務其實已經(jīng)被調度到了，而系統(tǒng)處于加快該任務執(zhí)行的目的，在系統(tǒng)設計上將其再次派發(fā)，如果還要和其他未被調度的任務一起競爭，那對這個任務來說是不公平的，也減弱了加速的作用。所以針對分片子任務，會將其放置到一個全局高優(yōu)先級隊列，優(yōu)先被選擇調度。

• 子任務調度節(jié)點選擇

  影響到子任務調度節(jié)點主要有以下因素：

  1. 機器類型

  機器類型分為硬件轉碼機器與普通轉碼機器，由于兩個環(huán)境中使用的編碼器不一樣，所以可能導致合并分片后的視頻會有瑕疵，因此我們選擇將子任務調度到與父任務相同的機器類型。

  2. 代碼版本

  不同版本的代碼可能導致轉出的分片無法很好的合并在一起，所以當出現(xiàn)這樣的版本迭代后，可以通過計算節(jié)點 worker 上的代碼版本，來確定子任務能調度到哪些其他計算節(jié)點上。

  3. 數(shù)據(jù)存儲

  當父 worker 上的任務并發(fā)大時，就會同時進行多個上傳下載的網(wǎng)絡傳輸，這樣會導致分片文件 IO 階段耗時增加，因此優(yōu)先選擇將子任務放在父 worker 上執(zhí)行，就會節(jié)省網(wǎng)絡 IO 與上傳下載耗時。

?掉隊者問題?

在分片轉碼場景中，掉隊者問題（straggler problems）是指在多個子任務中，如果大部分子任務已執(zhí)行完成，但還剩少數(shù)子任務遲遲未完成，父 worker 久久無法進入到下一個流程，從而導致該任務被阻塞住。這在分布式系統(tǒng)中是一種較為常見的現(xiàn)象，針對該問題的系統(tǒng)領域研究論文也是屢見不鮮。

對這個問題的解決方案很大程度會影響系統(tǒng)的效率。如果父 worker 選擇一直等待子任務，就可能出現(xiàn)任務過長時間的等待，這違背了我們提速的初衷。因此，基于保證該任務在有限時間內能被完成的原則，有以下幾個優(yōu)化方向：

1.冗余調度

這個方案參考了 Hadoop 中 MapReduce 對掉隊者問題的解決方案：當達到超時標準時，子任務還未完成，則父 worker 會針對同一個分片文件再次發(fā)送一個新 Tsak 子任務給 Dispatch center，讓其重新調度，并重新執(zhí)行。當有其中一個子任務完成則取消另一個。

這種做法是用空間換時間，不把希望只放在一個節(jié)點上，而是采取賽馬機制。但是，當這樣的情況發(fā)生較多時，則會產生大量的任務冗余，而且也不能保證新起的子任務不阻塞。

2.父 worker 接替完成

為了解決冗余調度中的不足之處，我們對其進行了優(yōu)化。當達到超時標準，而子任務還未完成時，則父 worker 會挑選完成進度最少的分片進行轉碼。同樣，其中一個任務完成則取消另一個冗余的任務。若還有子任務未完成，則繼續(xù)挑選，自己完成轉碼，直到所有子任務完成為止。

上述第二種方案較第一種方案的區(qū)別在于冗余任務不會重新調度到其他 worker 上執(zhí)行，而是優(yōu)先讓父 worker 來冗余執(zhí)行。這樣，父 worker 上會持續(xù)對分片進行轉碼，直到整個 job 完全完成。最大的優(yōu)點是：在不會無限制的消耗資源下，保證父 worker 不會處于無限等待狀態(tài)中，只有在少數(shù)情況下，當父 worker 負載較高時，會考慮使用其他擁有空閑資源的 worker。

?子任務進度跟蹤?

在父 worker 挑選子任務執(zhí)行時，需要收集子任務的進度后選擇進度最慢的子任務進行冗余執(zhí)行。在計算任務進度時，我們將一次轉碼分為這四個階段：等待調度、下載與準備、轉碼計算執(zhí)行、上傳與收尾。

不同階段的開始，表示到達不同的進度：

等待調度0% → 下載與準備20% → 轉碼計算執(zhí)行30% → 上傳與收尾90% → 結束100%

其中，轉碼計算執(zhí)行占70%，也是執(zhí)行速度無法保證的一個階段，所以需要詳細計算進度，轉碼執(zhí)行流會定期輸出 metric 日志，并進行監(jiān)控計算，當前轉碼進度 = 已轉碼時長（time 字段）/ 需轉碼時長 。

?HLS/DASH 封裝?

HLS 格式與其他封裝格式不同之處在于其會有多個 ts 文件與 m3u8 文件，對轉出 HLS 視頻的任務進行分片轉碼，會增加分片視頻傳輸與管理的復雜性。因此我們對此問題的解決方案是先將源視頻轉成 mp4 視頻，然后在父 Worker 上合并后，再對整個視頻轉換 HLS 封裝。

測試數(shù)據(jù)

通過記錄并對比同一個視頻轉為不同分辨率視頻的速率，我們可以發(fā)現(xiàn)各個單個的優(yōu)化措施對轉碼速度都有不同程度的提升。在實際線上場景，我們通常會根據(jù)用戶設定、視頻屬性決定綜合使用某幾項優(yōu)化方式。

測試視頻1屬性：

Duration: 00:47:19.21, bitrate: 6087 kb/s

Stream #0:0: Video: h264 (High), yuv420p, 2160x1216, 5951 kb/s, 30 fps

Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp, 127 kb/s

測試視頻2屬性：

Duration: 02:00:00.86,bitrate: 4388 kb/s

Stream #0:0: Video: h264 (High), yuvj420p, 1920x1080, 4257 kb/s, 25 fps

Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp, 125 kb/s

結語

以上就是本文的全部內容，網(wǎng)易云信轉碼團隊主要通過調度優(yōu)化、硬件能力、自研編碼、分片轉碼等維度切入，提升視頻轉碼速度，測試結果顯示轉碼提速效果顯著。另外著重介紹了云信轉碼系統(tǒng)中對分片轉碼模塊的主要設計。我們也會持續(xù)進行技術探索，實現(xiàn)提速以及更多的場景覆蓋。后續(xù)的系列文章中，我們還會對集群資源調度算法、硬件轉碼實踐等其他方面的內容進行分享，也歡迎持續(xù)關注我們。

?作者介紹?

羅微恒，網(wǎng)易云信高級服務端開發(fā)工程師，碩士畢業(yè)于武漢大學計算機學院，網(wǎng)易云信轉碼團隊核心成員，目前負責云信媒體任務處理系統(tǒng)設計與開發(fā)工作，致力于提升云信視頻轉碼服務質量。

?相關推薦閱讀?

• 技術系列課回顧 | 直播點播窄帶高清之 JND 感知編碼技術
  

• 技術系列課回顧 | 網(wǎng)易云信線上萬人連麥技術大揭秘
  

• 技術干貨 | 網(wǎng)易云信大規(guī)模聊天室系統(tǒng)架構解析

總結

以上是生活随笔為你收集整理的技术实践 | 网易云信视频转码提速之分片转码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。