東南亞各市場的網絡環境複雜多變、差異極大，如何在有限網絡條件下提供穩定、高清的視訊體驗是我們面臨的一大挑戰。基于此，本次分享将介紹 Shopee 在東南亞視訊業務落地上的方案，在畫質提升上做出的努力，以及一些性能提升成本控制方面的優化。
在 8 月 6 日舉辦的 LiveVideoStack 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 -> RD mode decision */
/* mbrd == 2 -> RD refinement satd cost */
/* 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 編碼能力，進一步提高視訊使用者體驗。
本文作者
Zhixing，來自 Shopee Multimedia Center 團隊。
來源:微信公衆号:Shopee技術團隊
出處:https://mp.weixin.qq.com/s/fYPfx4qOP2k2qlVkhzInmA