東南亞各市場的網絡環境復雜多變、差異極大，如何在有限網絡條件下提供穩定、高清的視頻體驗是我們面臨的一大挑戰。基于此，本次分享將介紹 Shopee 在東南亞視頻業務落地上的方案，在畫質提升上做出的努力，以及一些性能提升成本控制方面的優化。

在 8 月 6 日舉辦的 LiveVideoStackCon 2022 上海站大會中，Shopee 視頻技術團隊負責人 Zhixing 分享了 Shopee 視頻處理技術的后臺應用，本文根據演講內容整理而成。

1. 背景

隨著 Shopee 電商業務在東南亞等市場展開，視頻和電商結合的應用迅速落地。然而，當地許多用戶使用的手機配置有限，這些手機在視頻編解碼、圖像處理方面存在不小的性能瓶頸。

并且，當地網絡基礎設施建設還不太完善，在這樣的網絡條件下，如何穩定且高質量地傳輸媒體數據成為一大挑戰。

另外，海量的視頻文件和直播視頻處理也給 Shopee 后臺帶來了巨大的壓力。那么 Shopee 是如何通過技術手段來解決這一系列問題的呢？

本次分享的內容大致分為四個部分：第一部分是 Shopee 視頻相關的產品介紹；第二部分是 Shopee 視頻業務后臺的技術方案；第三部分是 Shopee 高清低碼轉碼技術，以及 RTC 場景視頻編碼技術；第四部分是我們在性能提升和節省算力成本上做的一些優化。

2. Shopee 視頻技術落地產品

先來看看 Shopee 有哪些與視頻相關的產品。

作為電商平臺，Shopee App 是我們的主要業務，涵蓋了 feeds 流、直播帶貨、點播等視頻類服務。其中，短視頻服務 Shopee Video 目前也已經在東南亞個別市場上線。

Shopee 的數字銀行業務 SeaBank 在部分場景下也用到了視頻服務，例如在線開戶環節。用戶發起開戶請求，客服接聽，通過視頻畫面在線認證身份信息。

此外，公司內部的通訊工具 SeaTalk 也計劃在語音通信功能的基礎上，新增視頻會議能力。

3. Shopee 視頻相關后臺服務

針對上述應用，我們開發了哪些視頻相關的后臺服務呢？

3.1 直播/點播轉碼

首先是 Shopee App 的轉碼服務，涉及點播和直播轉碼兩個轉碼平臺。有一些 AI 增強類的前置處理，一幀耗時比較長，對于點播業務來說，這不是什么問題，只是轉碼耗時增長。而對于直播業務來說，就需要考慮效率問題了，比如幀率 30，最多一幀只能耗時 33ms，如果串行進行所有前置處理，就會使得出幀幀率小于輸入幀率，導致視頻幀堆積的問題。

于是，我們設計了流水線的視頻處理架構，將耗時較短、不影響主流程的處理節點放在同一個 region 中，串行處理，耗時長的節點單獨一個 region，region 與 region 之間并行執行，中間通過隊列通信。這樣，只需要任意一個處理節點耗時保證在幀 duration 范圍內，就能滿足業務要求。

我們可以看到中間這張彩色的示意圖，如果是串行處理，每一幀的耗時就等于每一個節點耗時相加。然而流水線處理的話，每一幀的耗時取決于耗時最大的處理節點。

上圖為 Shopee 的直播/點播轉碼服務架構圖。點播轉碼集群分為內部 Prado 容器集群和云主機集群，MMS 點播平臺是我們的上游服務，該平臺可以根據負載自由調度，選擇使用 Prado 轉碼或是云主機轉碼。

說個題外話，為什么這里會有兩種集群？近兩年因為疫情，服務器采購比較困難，于是公司的 SRE 建議我們，這類對數據安全性要求沒有特別高的服務可以切到云主機，以加快業務落地。

對于轉碼后的視頻畫面質量，我們也有內部的畫質數據平臺 AWCY，提供編碼畫質監控能力。

3.2 直播連麥

上圖是 Shopee App 的直播連麥服務架構。連麥雙方通過 RTC-SFU 服務通信，觀眾通過 HTTP-FLV 觀看直播。

這里值得注意的是，通常云廠商為了后臺的穩定性，將連麥服務的邏輯簡單化了，不管房間是否有連麥主播，都采用轉碼的方式處理視頻流。而既然有轉碼，就涉及到視頻編碼環節，若只有一路主播的時候也轉碼，會浪費大量算力資源。

為了節省計算資源，Shopee 主播視頻采用了 H.264 編碼。在單個主播的時候，我們采用直接轉封裝的方式處理主播的視頻；當有連麥者接入的時候，采用混流轉碼的方式處理視頻；連麥者離開后，再次返回到轉封模式。

而 MCU 后臺處理了這種模式之間交替切換的問題，通過緩存 GOP 的方式解決從單主播切換到連麥模式的場景，通過等待新的 GOP 的方式解決從連麥模式切換到單人模式的場景。

線上大部分時候，在房間只有單個主播的場景下，CPU 的平均負載較低，大大提高了集群的并發能力。單臺機器如果進行轉碼，最多支持 20 路主播；如果不進行轉碼，目前通過壓測數據來看，至少支持 200 路主播轉發。

這一套方案也用于 SeaBank 在線開戶系統，對開戶通話過程進行錄制。區別在于 SeaBank 系統只有混流模式。

3.3 多人會議混流

對于 Shopee 內部通訊軟件 SeaTalk，我們提供了多人會議混流服務作為技術能力儲備（目前該功能還未上線），混流模塊中嵌入了開源軟件 OWT 和 mediasoupclient 的核心模塊，并且在 OWT 模塊上增加了 3 幀的緩存隊列，以平滑混流視頻幀。會議混流系統支持 RTMP 和 WebRTC 接入。

3.4 視頻后臺編輯

針對 Shopee 的短視頻產品 Shopee Video，我們開發了一套后臺編輯服務，用于完成一些 2D 特效，例如圖片序列轉視頻、添加背景音樂、畫面切割、文字動畫、視頻轉場、背景模糊等。目前通過 CPU 執行 Xvfb 虛擬顯存的方式完成 gltransition 的轉場效果。

4. 高清低碼

隨著 Shopee App 中帶貨直播業務量逐漸增長，提升直播用戶畫質體驗的需求也日益強烈。另一方面，在東南亞的網絡條件下，直播分辨率很多還是 360p 或 270p，碼率 300-500k。

起初，大部分 Shopee 帶貨主播流沒有轉碼，為了適配直播觀眾下行參差不同的網絡情況，主播甚至用更低的分辨率和碼率開播，來提高觀眾側的流暢度，當然這種做法以犧牲清晰度為代價。

在考慮用戶觀看體驗，并綜合視頻轉碼成本等多種因素后，Shopee 決定投入自研視頻轉碼業務。與業界常見做法類似，Shopee 的直播轉碼也分為普通轉碼和高清低碼轉碼。

普通直播轉碼集群用 NVIDIA T4 顯卡硬編碼，來支持更多直播轉碼。測試數據顯示，直播帶貨場景下，一張 NVIDIA T4 顯卡能編碼 30 路，相較于 CPU 成本有一定優勢。另外一部分是高清低碼轉碼，使用 CPU 轉碼，編碼器是基于 x264 優化后的版本。

上圖是 Shopee 直播高清低碼和云廠商高清低碼的畫質對比，左邊可以看出來 Shopee 轉碼畫質明顯優于云廠商 A，和右邊的云廠商 B 相比，在塊效應的處理上也有細微優勢。那么 Shopee 的高清低碼轉碼是如何做到的呢？

4.1 視頻處理的一般流程

先來大概了解一下視頻轉碼需要經過哪些環節：

第一步解碼得到 YUV 畫面數據；

然后經過前置處理，包含了 ROI 背景 gblur 濾波、銳化、AI 增強；

接著將 YUV 數據送進編碼器，進入預編碼環節，主要步驟是下采樣、Scenecut 關鍵幀判斷，幀類型決策、AC 能量值計算、MBTree 等；

下一步進入編碼環節，包括幀內/幀間預測編碼、RDO、Deblocking、參考幀管理等步驟；

最后就是進入量化和熵編碼環節，最終輸出 NALU 單元。

上面步驟中藍色部分是 Shopee 在 x264 基礎上做過優化的節點，接下來會一一講解。

4.2 Shopee 高清低碼優化方案

4.2.1 前置處理

1）CDEF 算法

在前置處理時，參考 AV1 中實現的 CDEF 算法，抽出來作為一個 FFmpeg 濾鏡，該算法主要用于解決由于過度壓縮導致的物體邊緣振鈴效應。通過該濾波算法之后，畫面中的物體邊緣會更加平滑。

CDEF 大致可以理解為首先計算當前 8x8 的塊在預設的八個方向塊上的殘差，選擇殘差最小的作為確定的角度方向，然后找到對應的角度方向矩陣進行濾波。圖中最右邊是濾波后的效果，可以看到樹枝的邊緣更加平滑了。

2）3D 降噪

常見的傳統降噪算法 FFmpeg 中也有一些濾鏡實現，比如 hqdn3d、bm3d 等。hqdn3d 參考的點較少，運動劇烈時效果不佳。bm3d 需要額外計算運動向量，速度極慢。

我們在編碼器內置的 3D 降噪算法通過復用運動向量的方法規避了效果差和速度慢的缺點。利用前后幀的預測信息，在預編碼中得到的運動向量作為依據，找到被參考幀對應的塊，作為濾波的參考塊，然后通過雙邊濾波算法，對當前塊進行濾波。

這樣一來，因為復用了運動向量，從而能夠較好地對當前的塊進行降噪濾波，也減少了計算復雜度。我們在 x265 也實現了同樣的算法。

4.2.2 分類參數

常見的分類編碼參數往往通過人為主觀分類，例如游戲、UGC 視頻、影視劇等。而考慮到主觀分類對于編碼器提高 BD-rate 不一定是最佳的，Shopee 采用了一種逆向的思維方法，先抽出來幾個不增加編碼復雜度，主要影響畫質的參數：B 幀個數、B 幀決策算法、B-pyramid、B 幀層次結構、QComp 等。

首先將這些參數分成性價比最高的八組（當然這八組是通過我們線上的視頻跑出來的結論），然后分別得出圖中幾組參數的最佳 SSIM BD-rate 收益——這里的收益是相對于我們線上統一的編碼參數而言，把最佳 BD-rate 視頻，相同參數的作為一組，然后針對這一組視頻提取特征，進行訓練，使用訓練完的模型對線上視頻進行分類。

手動參數分類測試 BD-rate 收益最大 2.6%，模型分類 BD-rate 提升取決于模型分類的準確性，目前通過模型分類收益 1.4% 左右，模型還在進一步改進中，預期是接近手動分類 BD-rate 收益最大 2.6% 的目標。

4.2.3 編碼器優化

1）VBV - Adapt CRF

在編碼器碼控方面，我們也做出了一些優化。如圖，這是 VBV + CRF 碼控模型示意圖，一邊注水，注水速度為 maxrate*幀duration；一邊放水，放水速度為實際編碼碼率。

當水位過低時，發生下溢，增大 QP 值，降低編碼碼率。當水位過高，發生上溢，減小 QP 值，增大編碼碼率。實際編碼檔位的 maxrate、bufsize 參數限制了水池的大小，使得復雜視頻畫面為了達到目標 CRF 畫質，經常發生下溢，當碼率不足時，大幅度降低了高復雜度畫面的畫質，比如出現嚴重塊效應。

我們通過動態調整 CRF 值的方式，讓平均畫質始終處于 VBV 限制范圍內。當發生下溢時，增大 CRF 值，降低目標畫質；當發生上溢時，減小 CRF 值，提高目標畫質，以此達到提升視頻平均質量的目的。通過線上大量視頻測試，BD-rate 提升了 1.2%。

2）Hierarchy B + 時域濾波

Shopee 編碼器對 BD-rate 提升最多的優化是分層 B 幀結構。

如圖所示，左邊是社區版本 x264 編碼出來的 B 幀結構，右邊是優化后的 B 幀結構。由于右邊的 B 幀分了更多層，從圖上可以很直觀地看出來，參考幀和被參考幀的距離更近，參考關系更優。

另外，分層 B 幀使用先確定 miniGOP，然后二分的方式決策參考關系和層次，相較于社區版的 Adapt B 和 Viterbi B 幀決策，速度更快。以下是我們測試的 BD-rate 提升和幀率提升收益。

另外，決策完參考關系之后，還可以通過對編碼幀進行時域濾波，讓編碼幀更接近參考幀，減小殘差，以提高 BD-rate，收益大概在 2% 左右。

3）ROI（GBlur 背景）

為了適配東南亞的網絡質量，Shopee 轉碼服務提出了一種 ROI 轉碼檔位。以往常見的 ROI 編碼，單純通過增大非 ROI 區域的 QP 值來降低非 ROI 區域的畫質，然后把 bits 節省下來，減小 ROI 區域 QP 值來提高畫質。

但是這樣帶來一個問題，非 ROI 區域看起來塊效應非常明顯，和 ROI 區域有明顯割裂感。于是，我們對非 ROI 區域進行高斯模糊濾波之后再 ROI 編碼，效果看起來比原來的 ROI 編碼好很多。

如圖所示，左邊是原圖，中間是扣下來的 ROI 區域，右圖是高斯模糊之后 ROI 編碼的效果。

4）長期參考幀

為了支持后臺視頻編輯的服務，我們在編輯服務編碼器中增加了長期參考幀。

在剪輯視頻的時候，可能會出現一段節目中間要植入廣告的場景，如果按照原生的 x264 幀類型決策策略，會發生 scenecut，決策為 IDR 幀，然而我們可以看到，這里中間植入的廣告的前后畫面很有關聯性。

于是我們把發生 scenecut 前額視頻幀緩存在編碼器參考幀隊列中，并標記為長期參考幀，當后面的視頻幀出現 scenecut 的時候，再和隊列中的長期參考幀 scenecut 決策一次，如果決策結果均為發生 scenecut，則標記為 IDR，反之編碼為 P 幀。如此優化后，BD-rate 提升 6% 左右，不過該策略僅適用于視頻剪輯的場景。

5）分級 RDO

另外，我們還在 RDO 方面做了一些優化。

RDO 是編碼器進行二次編碼，把重建塊和原畫之間的殘差作為失真，為了盡量減小失真，對幀內/幀間預測模式、運動向量、QP 值重新決策的過程。它們的決策強度都是依次遞增的，意思是如果要打開 QP RD，就一定要開運動向量，模式決策 refine。

/*mbrd==1->RDmodedecision*/ /*mbrd==2->RDrefinementsatdcost*/ /*mbrd==3->QPRD*/

于是我們把 QP RD 單獨拿出來，通過新增的參數控制開關，在犧牲了一定速度的條件下，達到了 BD-rate 3% 的收益。

6）時域 SVC

針對 RTC 場景，我們也做了一些編碼側的優化。

RTC 一般是沒有 B 幀的，為了解決群組會議用戶網絡質量參差不齊的問題。我們將 P 幀也進行了分層。層級之間的參考關系如圖所示，上層的 P 幀永遠參考下層的幀。

這樣一來，我們在傳輸過程中可以任意丟棄上一層的 P 幀，而不影響解碼播放。下行帶寬不足的時候， 在一個 miniGOP 內部，上層的 P 幀可以根據實際網絡情況丟棄，以降低帶寬，從而保證視頻的流暢性。

5. 性能優化

5.1 編碼器端上優化

在線上視頻業務中，我們曾遇到過一些問題。有一些配置較低的手機，在光線不是很好的情況下，拍出來的畫面無法看清畫面中必要的的文字信息。于是我們對手機上采集到的畫面進行了銳化，讓文字看起來更清晰一些。

然而測試發現，對于東南亞的手機配置，這樣的算法發熱太嚴重，即便銳化算法是參考了 FFmpeg 的 USM，已經是通過橫縱向狀態機復用和多線程優化過的版本，銳化一幀 720p 普遍耗時還是有 15-20ms，而且手機發熱嚴重。

于是我們針對 3x3 的 USM 模版，用 NEON 匯編指令優化了銳化函數，把一些點積、累加運算通過 SIMD 指令并行處理，銳化處理的幀率提高了 7 倍，手機也不再發熱。

5.2 一入多出編碼

東南亞的機房機器成本同樣很高，為了節省服務器機器資源，在點播后臺轉碼服務中，我們也做了一些成本優化。

Shopee App 需要將一個點播視頻轉碼 6 個檔位，不同的分辨率和碼率。我們通過對一些轉碼中間數據復用的方式很大程度上降低了轉碼服務集群的成本，首先我們復用了前置處理，包括 AI 增強，把同一個視頻文件轉碼多個檔位的請求調度到同一臺主機上，以復用前置處理結果。

其次，我們通過復用編碼器 lookahead 幀決策、MBTree 等信息。針對同一個視頻文件的轉碼，我們通常只需要對其中一個檔位的視頻做幀決策，其他的檔位直接復用幀類型信息。在編碼環節中復用運動向量，skip 塊等信息來減少運算量。

經過測試，有參考信息的轉碼檔位能節省 50% 的運算量。復用的轉碼檔位越多，節省的 CPU 算力也越多。

以上就是本次分享的主要內容。接下來我們還會發布在 x265 編碼器上的一些優化，在一些視頻業務上支持 H.265 編碼能力，進一步提高視頻用戶體驗。

審核編輯 ：李倩