在騰訊廣告的流量中，影片所佔比例逐年快速提升，影片抽幀這裡如果出現時耗或吞吐瓶頸（特別是針對高 FPS 抽幀的情況），很容易影響到後續的特徵提取以及模型預測效能。在當前的廣告影片 AI 推理服務中，抽幀往往佔據了其中大部分時耗，因此，影片抽幀的效能對於影片內容理解服務的時耗和整體資源開銷，有著舉足輕重的地位。
影片抽幀的幾個步驟，計算量非常大，傳統的 CPU 方式抽幀往往受限於 CPU 整體的計算吞吐，很難滿足低時延高效能要求。因此，使用 GPU 加速等手段，來對影片抽幀做極致的效能最佳化是必然。
騰訊廣告實現了影片解碼、影象處理與影象編碼的全 GPU 流程，經驗表明，單個 GPU 的影片解碼算力與 8 個 CPU 核大致相當，而且 GPU 做影象處理遠比 CPU 更有效能和成本優勢。
NVIDIA GPU 具備單獨的硬體編解碼計算單元，從早期釋出的 Maxwell 架構到最新的 Ampere 架構，都有完善的 API 支援，並且 GPU 上為數眾多的 CUDA 核心也特別適用於影象資料並行處理加速。目前廣泛使用的推理晶片 NVIDIA T4 GPU，包含兩個獨立於 CUDA 的解碼單元，且支援大部分主流的影片格式，是本案例的應用型號。
影片抽幀流程大體上包括以下幾個步驟：影片解碼、幀色彩空間轉換、落盤方式的 JPEG 編碼，如果非落盤，則對解碼出來的影片幀做預處理，然後交給模型進行特徵提取或預測。
（圖片來源於騰訊授權）
其中幀色彩空間轉換、JPEG 編碼都涉及畫素級別計算，非常適合使用 GPU CUDA kernel 來做平行計算加速。此外，影片解碼後得到的幀都是未經壓縮的原始資料，資料量很大，如果解碼是在 CPU 上進行，或者 GPU 解碼後自動傳回了 CPU，則需要頻繁做 device（視訊記憶體）與 host（主存）之間的原始幀資料來回複製，IO 時耗長且資料頻寬擁塞，導致時延明顯增加。因此，該方案的主要目標是儘可能減少 host 與 device 間的資料 IO 交換，做到抽幀過程全流程 GPU 異構計算，充分利用 NVIDIA GPU 自帶的硬體解碼單元 NVDEC，最大限度減少影片解碼對於 CPU 以及 GPU CUDA 核心佔用的同時，儘可能低延時、高吞吐地處理影片抽幀以及後續的模型推理。
具體來說，本方案主要從計算和 IO 兩個方面著手，解碼部分充分利用了 GPU 通常閒置的 NVDEC 解碼器，其他步驟以畫素或畫素塊計算為主，因此使用 CUDA kernel 做並行加速。IO 方面，由於中間過程是原始幀，GPU 資料頻寬有限，該方案實現了全流程 CPU 和 GPU 無幀資料交換，最大程度提升效能和吞吐，確保影片 AI 推理服務的 GPU 利用率。
計算最佳化
1. 硬解碼
當前線上主力的 GPU 推理卡 T4、P40，以及後續即將升級的 A 系列，主流的影片編碼格式基本都已支援，各卡型支援的具體格式如下：
（圖片來源於騰訊授權）
呼叫 GPU 硬解碼主要有兩種方式，一種是直接使用 NVIDIA 官方提供的 Video Codec SDK，另一種方式是使用 FFmpeg，其已經封裝了對 GPU 硬解碼的支援。考慮到目前 T4 GPU 對影片格式的支援還不夠完善，因此本文使用的是 FFmpeg 方式，如果遇到 GPU 不支援的影片格式，只需修改解碼器型別即可快速降級到 CPU 解碼方案，CPU 和 GPU 兩種模式抽幀的程式碼邏輯也較為統一。
以下分別以 FFmpeg CPU 4、8、16 執行緒，以及 GPU 硬解碼方式，抽取線上 100 個廣告影片做離線測試，平均時耗對比如下（CPU 為 2020 年釋出的主流伺服器 CPU）：
（圖片來源於騰訊授權）
注：影片平均大小約 15M，平均時長 26s，大部分為 720P 影片；FFmpeg 建議最大解碼執行緒數 16
分配給 GPU 模型推理服務的 CPU 核數一般不會太多，因此以 FFmpeg 8 執行緒、2 worker（在本文中是指單程序多例項的方式）做效能壓測，1000 個廣告影片測試資料如下：
（圖片來源於騰訊授權）
由此可見，在 GPU 線上推理環境，如果充分利用 T4 GPU 2 個 NVDEC 硬體解碼模組，可在幾乎不影響線上服務 CPU、CUDA 原有 workloads 計算的情況下，額外增加一倍解碼算力，抽幀 QPS 可在原有基礎上翻倍。此處應注意，不同架構 GPU 所附帶的 NVDEC 硬解模組數不同，並且 NVDEC 不支援外部再用多執行緒操作解碼，應當根據 NVDEC 模組數選擇正確的多例項多 worker 進行解碼。例如 T4 GPU 有 2 個 NVDEC 硬解碼模組，如果只用單例項，則硬解模組利用率將不會超過 50%。如果服務對吞吐的要求高於時延，則此處 GPU 硬解碼的 worker 數可以設為大於 n，充分壓榨硬體解碼模組。
2. CUDA 色彩空間轉換
影片解碼後得到的幀為 YUV 格式，而通常模型預測或其他後續處理一般需要 RGB/BGR 畫素格式，因此需要做一次色彩空間轉換，將 YUV 幀轉換為模型需要的 RGB 格式。傳統方式是呼叫 FFmpeg 的 swscale 模組來實現，但是該方式只支援在 CPU 進行計算，需要做一次 device 到 host 的資料 IO，並且非常消耗 CPU 資源，計算並行度也不高。統計發現，swscale 計算耗時佔比接近 40%。
YUV 到 RGB 格式的轉換是 3x3 的常量矩陣與 YUV 三維向量相乘，即逐畫素地將明度 Y、色度 U、濃度 V 三個分量按公式線性變換為 R、G、B 三色值（這裡的常量矩陣的值取決於影片所採用的顏色標準，比如 BT.601/BT.709/BT.2020，可參見 Video Codec SDK 裡面的示例），因此可以很方便地將計算過程改為一維或二維執行緒塊的 CUDA kernel 呼叫，充分利用 GPU 數以千記的 CUDA 核心平行計算來做提速。
**效能：**對線上 100 個廣告影片做效能對比評測，CUDA kernel 呼叫相對於 CPU 的 swscale 方式平均提速在 20 倍以上，並且影片清晰度越高，優勢越明顯。
（圖片來源於騰訊授權）
3. CUDA JPEG 編碼
如果是在影片預處理等場景，則需要對抽幀結果做 JPEG 編碼後再落盤儲存。JPEG 編碼具體流程如下：
（圖片來源於騰訊授權）
雖然不同於色彩空間轉換的逐畫素操作，但也是將整張圖片劃分為 8x8 畫素的小分塊分別進行離散餘弦變換、量化、Huffman 編碼等處理，同樣非常適合用 GPU CUDA core 計算單元來做並行加速。NVIDIA 從 CUDA Toolkit 10 開始也已經封裝了 nvJPEG 模組提供 JPEG 編碼能力。
需要說明的是，使用 GPU 做 JPEG 編碼，與 CPU JPEG 編碼存在一定比例的畫素差異。確保 JPEG 檔案頭中各項引數一致的情況下（壓縮質量、量化表、Huffman 表均相同），實測畫素差異比在 0.5% 左右。由於 JPEG 編碼為有失真壓縮，因此解碼後依然存在畫素差異，有可能導致模型給出的預測結果存在偏差。例如 OCR 的目標檢測模組，分別使用 CPU 和 GPU 編碼的 JPEG 影象作為輸入，預測得到的檢測框座標值在部分 case 上存在一定偏差，從而有機率導致文字識別結果出現不一致。一種可行的解決方案，是模型訓練也使用 GPU JPEG 編碼的圖片作為輸入，保證模型訓練和推理的輸入一致性，從而確保模型推理效果。
**效能：**實測線上 1000 個廣告影片，CUDA 方式 JPEG 編碼約有 15~20 倍效能提升，同樣清晰度越高效能優勢越大：
（圖片來源於騰訊授權）
IO最佳化
FFmpeg 使用 GPU 硬解碼後，得到的影片幀格式為 AV_PIX_FMT_NV12，透過 NVIDIA 提供的 cudaPointerGetAttributes API 做指標型別檢查，為 Host 端記憶體指標。也就是說呼叫 NVDEC 模組解碼後，預設對影片幀做了一次 device 到 host 的傳輸。
由於這裡的影片幀均為未壓縮的原始畫素幀，且原始影片的所有 FPS 幀都會做該處理，會佔用大量 GPU 與 host 端記憶體的資料頻寬。若有辦法做到 GPU 硬解後的影片幀，不預設傳回到 host 端，而是直接快取在視訊記憶體等待後續計算，則可以無縫對接後續的模型推理或 JPEG 落盤，省去 device 與 host 端的來回兩次資料交換時耗，且大幅減輕 GPU 與 CPU 間的資料 IO 吞吐壓力。
為此，可使用 FFmpeg 的 hwdevice 相關介面，直接得到視訊記憶體中的影片幀。這樣得到的影片幀格式變為 AV_PIX_FMT_CUDA，且 Y 和 UV plane 的 data linesize 也由 1088 變為 1280，使用時需要注意。此時使用 cudaPointerGetAttributes 檢查 frame data 指標型別，已經是 device 端指標，由此打通了全流程異構抽幀的關鍵一環。
透過 NVIDIA Nsight Systems 抓取到的效能資料可見，cudaMemcpy 由之前的 DtoH & HtoD 來回傳輸變為一次視訊記憶體內部的 DtoD，時耗由 173ms x 2 變為 25ms，吞吐也有不少提升。此外，CUDA kernel 計算時間片的連續性也得到不少改善。
**效能：**實測線上 1000 個廣告影片，整體效能相較於非硬體緩衝區方式有 25% 左右的提升，GPU 硬解碼器 NVDEC 資源利用率提升約 30%。
（圖片來源於騰訊授權）
工程最佳化
本文以介紹 GPU 全流程抽幀方案為主，過程中為了把效能做到極致也涉及到一些工程最佳化：
- 透過視訊記憶體預分配+複用、AVHWDeviceContext 緩衝區 & JPEG 編碼器複用等手段，單次抽幀時耗可再最佳化百 ms 級別。
- 將 NVDEC 硬解碼、色彩空間轉換、JPEG 編碼、模型推理等步驟，利用 CUDA 多流，並對每個環節做 Pipeline overlap 並行化處理，可充分釋放每個步驟的最大計算效能，進一步提升計算吞吐和資源利用率。
（圖片來源於騰訊授權）
- 目前有不少演算法服務是基於 Python 進行開發&部署，本方案為保障高效能，使用 C++ 開發。透過 pybind11 基於 C++ 封裝 Python 抽幀 API，保障演算法開發部署的靈活性與效率的同時，確保高效能的抽幀能力。
- 不落盤方式，對接模型推理之前一般需要先做預處理操作，如果要做到全流程 GPU，需要將預處理改寫為 CUDA kernel 呼叫。這裡可以將常用的 CV 類預處理操作封裝為 CUDA 基礎函式庫，也可以使用 NVIDIA 已經封裝好的 NPP 模組、DALI 預處理加速框架等方案。
使用效果及影響
全流程時耗對比：
- 相較於 CPU 8 執行緒解碼，全流程有一倍左右的速度優勢，並且由於幾乎不佔用 PCIe 資料頻寬，對模型推理等 device&host 間資料 IO 基本無影響，在吞吐上也有不少提升。
- 相較於 Python 演算法常用的 ffmpeg-python 方式，有數倍效能提升。
（圖片來源於騰訊授權）
影片抽幀最佳化是影片 AI 推理最佳化中的重要一環，本方案從 GPU 硬體加速的角度出發，分別針對抽幀各步驟做效能分析&計算最佳化，解決了中間過程大資料量的原始影片幀 host 與 device 端資料 IO 交換問題，避免 GPU 與 CPU 間的 PCI-E 資料頻寬瓶頸，真正做到全流程 GPU 異構抽幀。基於此，可在 GPU 無縫對接後續的模型推理（不落盤）以及 JPEG 編碼（落盤）兩種主流的抽幀使用場景，是實現全流程 GPU 影片 AI 推理能力的先決條件。同時，充分利用了 GPU 推理環境通常閒置的 NVDEC 解碼晶片，對於整體服務時耗、吞吐，以及硬體資源利用率均有不錯的提升，降低了影片 AI 推理服務 GPU/CPU 算力成本，在算力緊缺的 AI2.0 時代有著非常重要的意義。
目前該方案已在騰訊廣告多媒體 AI 的影片人臉服務落地，解決了其最主要的抽幀效能瓶頸，滿足廣告流水對於服務的效能要求。更多影片 AI 演算法，特別是高 FPS 抽幀場景也在逐步接入最佳化中。
“後續，我們還將與英偉達一起，探索影片抽幀與模型推理的最佳結合方式，力求實現影片 AI 推理的極致效能。”騰訊廣告 AI 工程架構師， GPU 影片抽幀專案負責人向乾彪表示。
