科學與技術

實時 AI 視頻分析是一種基于人工智能的技術，可分析視頻流以檢測特定行為和事件。這種類型的系統通過人工智能機器學習引擎檢查來自監控攝像頭的視頻流來進行相關工作。該引擎使用一系列深度學習算法和程序來理解數據，并將數據轉換為可理解的、有意義的信息。

以車輛檢測這是任務為例，我們可以把 AI 視頻分析分為以下幾個通用步驟：

1.視頻流拉流

2.媒體解碼

3.圖像前處理縮放

4.深度學習推理，識別車輛

5.后處理畫框

6.媒體編碼傳輸

7.分析結果可視化呈現

圖：通用 AI 視頻分析流程

隨著邊緣計算技術的日漸成熟，我們逐步將 AI 算力與分析服務下沉到邊緣設備側，以獲取更好的實時性，并減少視頻流傳輸對于帶寬資源的占用。此時，AI Box 邊緣計算設備將作為媒體數據分析的核心節點，直接接入并讀取 IP 攝像頭編碼后的視頻流數據，進行實時的解碼和推理工作，并將結果數據推送至后端機房。后續配合視頻監控服務機完成對推理結果的后處理分析與告警，以及將編碼后的事件關鍵幀留存，以供人工追溯。

鑒于邊緣測的算力資源有限，大家不難發現這個流程中性能的瓶頸往往會發生在 AI Box 的視頻解碼或者是推理任務中。同時出于方案成本的考慮，我們也希望可以用相同的硬件資源，接入更多路的視頻流分析業務，因此如何進一步優化這部分的工作流程，便成為了本示例希望分享的核心重點。

圖：邊緣 AI 視頻分析架構

1.OpenVINO工具套件簡介

用于高性能深度學習的英特爾發行版 OpenVINO工具套件基于 oneAPI 而開發，以期在從邊緣到云的各種英特爾平臺上，幫助用戶更快地將更準確的真實世界結果部署到生產系統中。通過簡化的開發工作流程，OpenVINO工具套件可賦能開發者在現實世界中部署高性能應用程序和算法。

在推理后端，得益于 OpenVINO 工具套件提供的“一次編寫，隨處部署”特性，轉換后的模型能夠在不同的英特爾硬件平臺上運行，無需重新構建，有效簡化了構建與遷移過程。此外，為了支持更多的異構加速單元，OpenVINO 工具套件的 runtime api 底層采用了插件式的開發架構，基于 oneAPI 中的 MKL-DNN、oneDNN 等函數計算加速庫，針對通用指令集進行優化，為不同的硬件執行單元分別實現了一套完整的高性能算子庫，提升模型在推理運行時的整體性能表現。

這里值得提一句的是，目前 OpenVINO 2022.2版本可以直接支持英特爾最新的獨立顯卡產品（dGPU）執行推理任務。

可以參考文章：

官宣：支持英特爾獨立顯卡的OpenVINO 2022.2新版本來啦

2. 英特爾 oneAPI 簡介

英特爾 oneAPI 是一項行業倡議，旨在創建一個開放、基于標準的跨架構編程模型，在面對大量跨各種架構（CPU、GPU、FPGA 和其他加速器）的工作負載時簡化開發工作。它包括跨架構語言 Data Parallel C ++（基于 ISO C ++ 和 Khronos Group 的 SYCL）、高級庫和社區擴展。許多公司、研究機構和大學均支持 oneAPI。

作為 oneAPI 中最重要的高級庫組件之一，oneVPL （Intel oneAPI Video Processing Library）可以在英特爾的 CPU、GPU 等硬件平臺上實現對視頻數據的解碼，編碼與處理功能，支持 AVI，H.256 (HEVC)，H.264 (AVC)，MPEG-2，VP9 等多種媒體標準的硬件解碼能力。目前 oneVPL 已經適配以下型號的 GPU 硬件：

11thgeneration Intel Core processors with XeArchitecture GPUs

Intel Iris XeMAX

Intel Arc A-series graphics

Intel Data Center GPU Flex Series

Upcoming GPU platforms

更多關于英特爾硬件編解碼格式的支持可以參考

任務開發流程

該方案將依托于英特爾的 GPU 設備執行視頻分析業務，主要有以下幾個原因：

通常情況下，在性能和功耗等方面，相較 CPU 的軟解碼，GPU 中專用編解碼器往往可以提供更強大的硬件解碼能力，輸入視頻的分辨率越高，這里的性能差異也越明顯。

此外鑒于 GPU 設備在并行能力上的優勢，OpenVINO在調用英特爾最新的集成顯卡 iGPU 和獨立顯卡 dGPU 推理時，也能發揮出比較優異的吞吐量表現。

最后調用 GPU 推理也能最大化提升英特爾架構的資源利用率，在邊緣計算的任務架構中，系統不需要 GPU 來處理圖像的渲染業務，而 CPU 往往需要承擔更多資源調度方面的工作，通過將視頻分析任務搬運到 CPU 自帶的集成顯卡中，不光能充分利用這部分閑置的資源，并且可以減輕 CPU 上的工作負載，進一步優化方案成本。

因此我們要確保在整個視頻流分析鏈路中，中間數據可以被“保留”在 GPU 的內存中，避免與 host 之間額外的傳輸開銷，同時也減少在同一設備中的數據搬運，也就是所謂的“零拷貝”，從而實現 GPU 處理性能的最大化。

圖：GPU 視頻分析流水線

接下來我們就通過一個簡單的單通道示例，還看下如何優化 GPU 上的視頻分析服務。在這個示例中，輸入數據是一段 H.265 的視頻文件，我們可以把整個流水線分成以下4個部分，分別對應 oneVPL 和 OpenVINO工具套件中不同的組件接口。

1.視頻解碼 （Libva）

oneVPL依賴于Libva庫，通過對VA-API （Video Acceleration API）接口的上層封裝，實現了 GPU 硬件編解碼能力。在這個示例中關于解碼部分可以有以下幾個步驟被抽象出來：

利用 MFXVideoDECODE_Init 接口，通過 oneVPL session 初始化解碼模塊：

sts = MFXVideoDECODE_Init(session, &mfxDecParams);

向右滑動查看完整代碼

讀取視頻流，并封裝到 bitstream buffer 中：

sts = ReadEncodedStream(bitstream, source);

向右滑動查看完整代碼

調用 MFXVideoDECODE_DecodeFrameAsync 接口執行解碼任務，將解碼后的數據寫入 pmfxDecOutSurfac 地址

sts=MFXVideoDECODE_DecodeFrameAsync(session,
(isDrainingDec)?NULL:&bitstream,
NULL,
&pmfxDecOutSurface,
&syncp);

向右滑動查看完整代碼

2.圖像縮放（VPP）:

接下來使用 oneVPL 中的 VPP（Video processing functions）模塊來實現對于圖像的縮放處理，首先我們需要定義一些關鍵參數，例如輸出圖像的色彩通道與縮放后的圖像尺寸，這里為了能實現編碼輸出與推理輸入的零拷貝共享，我們需要將輸出的色彩格式設置為 NV12：

mfxVPPParams.vpp.Out.FourCC        = MFX_FOURCC_NV12;
mfxVPPParams.vpp.Out.ChromaFormat=MFX_CHROMAFORMAT_YUV420;
mfxVPPParams.vpp.Out.Width=ALIGN16(vppOutImgWidth);
mfxVPPParams.vpp.Out.Height=ALIGN16(vppOutImgHeight);

向右滑動查看完整代碼

利用 MFXVideoVPP_Init 接口，初始化 VPP 模塊：

sts = MFXVideoVPP_Init(session, &mfxVPPParams);

向右滑動查看完整代碼

將解碼后的輸出數據地址送入 MFXVideoVPP_ProcessFrameAsync 接口，進行圖像縮放處理，并以指定的色彩通道輸出：

MFXVideoVPP_ProcessFrameAsync(session, pmfxDecOutSurface, &pmfxVPPSurfacesOut);

向右滑動查看完整代碼

3.色彩空間與數據排布轉換（OpenVINO Preprocessing API）：

Preprocessing API 是OpenVINO 2022.1版本中新增加的一個功能，可以實現將一些常規的前處理操作以 node 節點的形式集成到OpenVINO模型的 runtime 執行圖中，從而實現將這部分計算過程加載到指定的硬件平臺進行執行，同時利用 OpenVINO 強大的模型加速能力，提升前處理任務性能，這里可以被支持的前處理任務包含：

精度轉換：U8 buffer to FP32

Layout轉換：Transform to planar format: from {1, 480, 640, 3} to {1, 3, 480, 640}

Resize ：640x480 to 224x224

色彩空間轉換：BGR->RGB

Normalization：mean/scale

圖：Preprocessing API 功能示意

這里我們將部分 VPP 不支持的前處理算子，通過 Preprocessing API 的方式將他們放到 GPU 上去執行，一方面可以減少 CPU 上任務的負載，一方面可以避免額外的 Device to Host 內存拷貝。查詢 Open Model Zoo 的預訓練模型說明可知，本示例用到車輛檢測模型的輸入數據通道要求為 BGR，數據排布為 NCHW，因此在調用 Preprocessing API 時，我們需要實現這兩種格式的轉換：

圖：vehicle-detection-0200 模型輸入要求說明

回到代碼部分，我們調用 pre_post_process 頭文件中的相應函數實現對 VPP 輸出數據的色彩空間轉換（YUV->BGR）和排布轉換（NHWC->NCHW），并且最終通過 build 方法，將這部分前處理任務集成到原始模型的執行圖中，生成新的 model 對象:

autop=PrePostProcessor(model);
p.input().tensor().set_element_type(ov::u8)
//YUVimagescanbesplitintoseparateplanes
 .set_color_format(ov::NV12_TWO_PLANES,{"y","uv"})
 .set_memory_type(ov::surface);
//Changecolorformat
p.input().preprocess().convert_color(ov::BGR);//Changelayout
p.input().model().set_layout("NCHW");
model=p.build();

向右滑動查看完整代碼

此處，NV12 會被拆分為 Y 和 UV 兩個分量，如果不執行 NCHW 的轉換，運行時會由于通道維度不匹配而報錯。

4. 模型推理（OpenVINO runtime）：

為了實現零拷貝的訴求，該示例中用到的 OpenVINO的“Remote Tensor API of GPU Plugin”相關接口，以實現與 VA-API 組件對于 GPU 內存中視頻數據的共享。具體步驟如下：

創建 GPU 中共享內存的上下文：

auto shared_va_context = ov::VAContext(core, lvaDisplay);

向右滑動查看完整代碼

獲取VPP輸出結果的句柄，并通過 create_tensor_nv12 接口將 VA-API surface 轉化并封裝成 OpenVINO的 tensor 內存對象：

lvaSurfaceID=*(VASurfaceID*)lresource;
//WrapVPPoutputintoremoteblobsandsetitasinferenceinput
autonv12_blob=shared_va_context.create_tensor_nv12(height,width,lvaSurfaceID);

向右滑動查看完整代碼

在推理請求中載入該內存對象，并執行推理：

infer_request.set_tensor(new_input0->get_friendly_name(),nv12_blob.first);
infer_request.set_tensor(new_input1->get_friendly_name(),nv12_blob.second);


//startinferenceonGPU
infer_request.start_async();
infer_request.wait();

向右滑動查看完整代碼

可以發現，不同于原始模型，這里輸入數據變成兩份，原因是在上一步調用 Preprocessing API 的過程中，我們將 NV12 還原到 Y 和 UV 兩個分量，所以原始模型的輸入數據數也要做相應調整。

參考示例使用方法

本示例已在 Ubuntu20.04 及第十一代英特爾酷睿 iGPU 及A RCA380dGPU 環境下進行了驗證。

1.下載示例

2.安裝相應組件和依賴

可以參考該示例倉庫中的README文檔進行環境安裝：

https://github.com/OpenVINO-dev-contest/decode-infer-on-GPU

3.下載預訓練模型

這個示例中我們用到了 Open Model Zoo 的 vehicle-detection-0200 模型用于對視頻流中的車輛進行檢測，具體下載命令如下：

? 4.編譯并執行推理任務

5.運行輸出

最終效果如下：

該示例會輸出每一幀畫面中被檢測到車輛的置信度，以及在畫面中的坐標信息等。

結論

利用 oneAPI 的 oneVPL 組件，以及 OpenVINO的 Preprocessing API 和 remote tensor 接口，我們可以在英特爾 GPU 硬件單元上構建從解碼，前處理，推理的視頻分析全流程應用，且沒有額外的內存拷貝，大大提升對 GPU 資源的利用率。隨著越來越多的英特爾獨立顯卡系列產品的推出，相信這樣一套參考設計幫助開發者在 GPU 平臺上實現更出色的性能表現。

審核編輯：湯梓紅