在基于NVIDIA平臺(tái)上推理時(shí)，通常會(huì)遇到讀取視頻進(jìn)行解碼然后輸入到GPU進(jìn)行推理的需求。視頻一般以RTMP/RTSP的流媒體，文件等形式出現(xiàn)。解碼通常有VideoCapture/FFmpeg/GStreamer等選擇，推理一般選擇TensorRT。

NVIDIA已經(jīng)為用戶提供了基于GStreamer插件拼裝的DeepStream Toolkit來解決上述需求，實(shí)現(xiàn)RTMP/RTSP/FileSystem到GStreamer再到TensorRT，從視頻數(shù)據(jù)的輸入到高性能解碼推理，再到渲染編碼，直到最終結(jié)果輸出。端到端的屏蔽了細(xì)節(jié)，易于上手使用，用戶只需要開發(fā)對(duì)應(yīng)GStreamer插件即可輕易實(shí)現(xiàn)高性能解碼推理。這個(gè)方案涵蓋了服務(wù)端GPU、邊緣端嵌入式設(shè)備的高性能支持。 由于項(xiàng)目的緣故，面臨了大規(guī)模（96路）視頻文件的同時(shí)處理，同時(shí)推理的模型種類有6種（Object Detection[Anchor base/Anchor free]、Instance Segmentation、Semantic Segmentation、Keypoint Detection、Classification），處理的模型約96個(gè)（分類器36個(gè)，檢測(cè)分割60個(gè)）。項(xiàng)目需要極高的靈活度（模型種類和數(shù)量增加變化）、穩(wěn)定性和高性能，考察DeepStream后發(fā)現(xiàn)其靈活度無法滿足需求，因此針對(duì)該需求，使用FFMPEG、NVDEC(CUVID)、CUDA、TensorRT、ThreadPool、Lua等技術(shù)實(shí)現(xiàn)了一套高性能高靈活性的硬編解碼推理技術(shù)方案，高擴(kuò)展性，靈活的性能自動(dòng)調(diào)整，任務(wù)調(diào)度。

解碼器

VideoCapture/FFMPEG/NVDEC

VideoCapture基于FFMPEG，如果單獨(dú)使用FFMPEG則可以做到更細(xì)粒度的性能控制，如果配合NVDEC則需要修改FFMPEG。

其中尤為重要的部分是：

a. 謹(jǐn)慎使用cvtColor，在OpenCV底層，cvtColor函數(shù)是一個(gè)多線程運(yùn)行加速的函數(shù)，即使僅僅是CV_BGR2RGB這個(gè)通道交換的操作也如此。他是一個(gè)非常消耗CPU的操作。

通過上面可以觀察到，具有64線程的服務(wù)器，也只能實(shí)時(shí)處理3路帶有cvtColor的視頻文件。沒有cvtColor時(shí)，指標(biāo)約為12路。也側(cè)面反映了CPU解碼效率其實(shí)很感人。 而cvtColor在CPU上運(yùn)行的替代方案是sws_scale，具有靈活的性能配置選擇。不過也僅僅是比cvtColor稍好一點(diǎn)，問題并沒有得到解決。 顏色空間轉(zhuǎn)換，第一個(gè)使用場景為H264解碼后得到的是YUV格式圖像，需要轉(zhuǎn)換為BGR（這個(gè)過程在VideoCapture中默認(rèn)存在sws_scale，輸出圖像為BGR格式）。第二個(gè)使用場景是神經(jīng)網(wǎng)絡(luò)推理所需要的轉(zhuǎn)換（訓(xùn)練時(shí)指定為RGB格式）。 解決方案是： 1) 使用BGR進(jìn)行訓(xùn)練，盡量避免顏色空間轉(zhuǎn)換； 2) 使用FFMPEG解碼，并輸出YUV格式，使用CUDA把YUV格式轉(zhuǎn)換為BGR，同時(shí)還進(jìn)行進(jìn)行標(biāo)準(zhǔn)化、BGRBGRBGR轉(zhuǎn)為BBBGGGRRR等推理常有操作。實(shí)現(xiàn)多個(gè)步驟合并為一個(gè)cuda核，降低數(shù)據(jù)流轉(zhuǎn)，提升吞吐量。例如yolov5，則可以把Focus也合并到一個(gè)cuda核中。如果需要中心對(duì)齊等操作，依舊可以把仿射變換矩陣傳入到cuda核中，一次完成整個(gè)預(yù)處理流程。 下圖為同時(shí)實(shí)現(xiàn)歸一化、focus、bgr到rgb、bgrbgrbgr轉(zhuǎn)bbbgggrrr共4個(gè)操作。

b. 僅考慮CPU解碼，使用FFMPEG可以配合nasm編譯(--enable_asm)支持CPU的SIMD流指令集(SSE、AVX、MMX)，比默認(rèn)VideoCapture配置的ffmpeg性能更好。同時(shí)還可以根據(jù)需要配置解碼所使用的線程數(shù)，控制sws_scale、decode的消耗。

編碼而言，ffmpeg可以使用preset=veryfast實(shí)現(xiàn)更高的速度提升于VideoWriter，設(shè)置合理的gop_size、bit_rate可以實(shí)現(xiàn)更加高效的編碼速度、更小的編碼后文件、以及更快的解碼速度。

c. NVDEC是一個(gè)基于CUDA的GPU硬件解碼器庫，CUVID（NVENC）是編碼庫。

地址是：https://developer.nvidia.com/nvidia-video-codec-sdk

對(duì)于ffmpeg配合NVDEC時(shí)，需要修改libavutil/hwcontext_cuda.c:356 對(duì)于hwctx->cuda_ctx 的創(chuàng)建不能放到ffmpeg內(nèi)部進(jìn)行管理。這對(duì)于大規(guī)模（例如超過32路同時(shí)創(chuàng)建解碼器時(shí)）是個(gè)災(zāi)難。硬件解碼的一個(gè)核心就是CUcontext的管理，CUcontext應(yīng)該在線程池的一個(gè)線程上下文中全局存在一個(gè)，而不是重復(fù)創(chuàng)建。TensorRT的模型加載時(shí)（cudaStreamCreate時(shí)），會(huì)在上下文中創(chuàng)建CUcontext，直接與其公用一個(gè)context即可。

對(duì)于沒有合理管理CUcontext的，異步獲取ffmpeg的輸出數(shù)據(jù)會(huì)存在異常并且難以排查。如果大規(guī)模同時(shí)創(chuàng)建32個(gè)解碼器，則同時(shí)執(zhí)行的程序，其前后最大時(shí)長差為32秒。并且由于占用GPU顯存，導(dǎo)致程序穩(wěn)定性差，極其容易出現(xiàn)OOM。

frames_ctx->format指定為AV_PIX_FMT_CUDA后，解碼出的圖像數(shù)據(jù)直接在GPU顯存上，格式是YUV_NV12，可以直接在顯卡上對(duì)接后續(xù)的pipline。

在ffmpeg解碼流程中，配合硬件解碼，需要在avcodec_send_packet/avcodec_decode_video2之前，將codec_ctx_->pix_fmt設(shè)置為AV_PIX_FMT_CUDA，該操作每次執(zhí)行都需要存在，并不是全局設(shè)置一次。

基于以上的結(jié)論為：

a) CPU編解碼，使用配置了nasm的ffmpeg進(jìn)行，避免使用VideoCapture/VideoWriter；

b) GPU編解碼，服務(wù)器使用配置了NVDEC的ffmpeg進(jìn)行，嵌入式使用DeepStream（不支持NVDEC）；

c) 避免使用cvtColor，盡量合并為一個(gè)cuda kernel減少數(shù)據(jù)扭轉(zhuǎn)實(shí)現(xiàn)多重功能。

CUDA/TensorRT

關(guān)于推理的一些優(yōu)化

a. 對(duì)于圖像預(yù)處理部分，通常有居中對(duì)齊操作：把圖像等比縮放后，圖像中心移動(dòng)到目標(biāo)中心。通?？梢允褂胷esize+ROI復(fù)制實(shí)現(xiàn)，也可以使用copyMakeBorder等CPU操作。

在這里推薦采用GPU的warpAffine來替代resize+坐標(biāo)運(yùn)算。原因是warpAffine可以達(dá)到一樣效果，并且代碼邏輯簡單，而且更加容易實(shí)現(xiàn)框坐標(biāo)反算回圖像尺度。對(duì)于反變換，計(jì)算warpAffine矩陣的逆矩陣即可（使用invertAffineTransform）。GPU的warpAffine實(shí)現(xiàn)，也僅僅只需要實(shí)現(xiàn)雙線性插值即可。

b. 注意計(jì)算的密集性問題。

cudaStream的使用，將圖像預(yù)處理、模型推理、后處理全部加入到同一個(gè)cudaStream中，使得計(jì)算密集性增加。實(shí)現(xiàn)更好的計(jì)算效率，統(tǒng)一的流進(jìn)行管理。所有的GPU操作均采用Async異步，并盡可能減少主機(jī)到顯存復(fù)制的情況發(fā)生。方案是定義MemoryManager類型，實(shí)現(xiàn)自動(dòng)內(nèi)存管理，在需要GPU內(nèi)存時(shí)檢查GPU是否是最新來決定是否發(fā)生復(fù)制操作。取自caffe的blob類。

c. 檢測(cè)器通常遇到的sigmoid操作，是一個(gè)可以加速的地方。

例如通常onnx導(dǎo)出后會(huì)增加一個(gè)sigmoid節(jié)點(diǎn)，對(duì)數(shù)據(jù)進(jìn)行sigmoid變?yōu)楦怕屎筮M(jìn)行后處理得到結(jié)果。Yolov5為例，我們有BxHxWx [(num_classes + 5) * num_anchor]個(gè)通道需要做sigmoid，假設(shè)B=8，H=80，W=80，num_classes=80，num_anchor=3，則我們有8x80x80x255個(gè)數(shù)字需要進(jìn)行sigmoid。而真實(shí)情況是，我們僅僅只需要保留confidence > threshold的框需要保留。而大于threshold的框一般是很小的比例，例如200個(gè)以內(nèi)。真正需要計(jì)算sigmoid的其實(shí)只有最多200個(gè)。這之間相差65280倍。這個(gè)問題適用全部存在類似需求的檢測(cè)器后處理上。 解決對(duì)策為，實(shí)現(xiàn)cuda核時(shí)，使用desigmoid threshold為閾值過濾掉絕大部分不滿足條件的框，僅對(duì)滿足的少量框進(jìn)行后續(xù)計(jì)算。

d. 在cuda核中，避免使用例如1.0，應(yīng)該使用1.0f。

因?yàn)?.0是雙精度浮點(diǎn)數(shù)，這會(huì)導(dǎo)致這個(gè)核的計(jì)算使用了雙精度計(jì)算。眾所周知，雙精度性能遠(yuǎn)低于單精度，更低于半精度。

線程池Thread Pool

主要利用了c++11提供的condition_variable、promise、 future、mutex、queue、thread實(shí)現(xiàn)。線程池是整個(gè)系統(tǒng)的基本單元，由于線程池的存在，輕易實(shí)現(xiàn)模型推理的高度并行化異步化。

使用線程池后，任務(wù)通過 commit提交，推理時(shí)序圖為：

當(dāng)線程池配合硬件解碼后，時(shí)序圖為：

此時(shí)實(shí)現(xiàn)了GPU運(yùn)算的連續(xù)化，異步化。GPU與CPU之間沒有等待。

資源管理的RAII機(jī)制

Resource Acquisition Is Initialization

在C++中，使用RAII機(jī)制封裝后，具有頭文件干凈，依賴簡單，管理容易等好處。

其要點(diǎn)在于：第一，資源創(chuàng)建即初始化，創(chuàng)建失敗返回空指針；第二，使用shared_ptr自動(dòng)內(nèi)存管理，避免丑陋的create、release，new、delete等操作；第三，使用接口模式，hpp聲明，cpp實(shí)現(xiàn)，隱藏細(xì)節(jié)。外界只需要看到必要的部分，不需要知道細(xì)節(jié)。

頭文件：interface.hpp

實(shí)現(xiàn)文件：interface.cpp

責(zé)任編輯：lq