在基于NVIDIA平臺上推理時,通常會遇到讀取視頻進行解碼然后輸入到GPU進行推理的需求。視頻一般以RTMP/RTSP的流媒體,文件等形式出現(xiàn)。解碼通常有VideoCapture/FFmpeg/GStreamer等選擇,推理一般選擇TensorRT。
NVIDIA已經(jīng)為用戶提供了基于GStreamer插件拼裝的DeepStream Toolkit來解決上述需求,實現(xiàn)RTMP/RTSP/FileSystem到GStreamer再到TensorRT,從視頻數(shù)據(jù)的輸入到高性能解碼推理,再到渲染編碼,直到最終結(jié)果輸出。端到端的屏蔽了細節(jié),易于上手使用,用戶只需要開發(fā)對應(yīng)GStreamer插件即可輕易實現(xiàn)高性能解碼推理。這個方案涵蓋了服務(wù)端GPU、邊緣端嵌入式設(shè)備的高性能支持。 由于項目的緣故,面臨了大規(guī)模(96路)視頻文件的同時處理,同時推理的模型種類有6種(Object Detection[Anchor base/Anchor free]、Instance Segmentation、Semantic Segmentation、Keypoint Detection、Classification),處理的模型約96個(分類器36個,檢測分割60個)。項目需要極高的靈活度(模型種類和數(shù)量增加變化)、穩(wěn)定性和高性能,考察DeepStream后發(fā)現(xiàn)其靈活度無法滿足需求,因此針對該需求,使用FFMPEG、NVDEC(CUVID)、CUDA、TensorRT、ThreadPool、Lua等技術(shù)實現(xiàn)了一套高性能高靈活性的硬編解碼推理技術(shù)方案,高擴展性,靈活的性能自動調(diào)整,任務(wù)調(diào)度。
解碼器
VideoCapture/FFMPEG/NVDEC
VideoCapture基于FFMPEG,如果單獨使用FFMPEG則可以做到更細粒度的性能控制,如果配合NVDEC則需要修改FFMPEG。
其中尤為重要的部分是:
a. 謹(jǐn)慎使用cvtColor,在OpenCV底層,cvtColor函數(shù)是一個多線程運行加速的函數(shù),即使僅僅是CV_BGR2RGB這個通道交換的操作也如此。他是一個非常消耗CPU的操作。
通過上面可以觀察到,具有64線程的服務(wù)器,也只能實時處理3路帶有cvtColor的視頻文件。沒有cvtColor時,指標(biāo)約為12路。也側(cè)面反映了CPU解碼效率其實很感人。 而cvtColor在CPU上運行的替代方案是sws_scale,具有靈活的性能配置選擇。不過也僅僅是比cvtColor稍好一點,問題并沒有得到解決。 顏色空間轉(zhuǎn)換,第一個使用場景為H264解碼后得到的是YUV格式圖像,需要轉(zhuǎn)換為BGR(這個過程在VideoCapture中默認(rèn)存在sws_scale,輸出圖像為BGR格式)。第二個使用場景是神經(jīng)網(wǎng)絡(luò)推理所需要的轉(zhuǎn)換(訓(xùn)練時指定為RGB格式)。 解決方案是: 1) 使用BGR進行訓(xùn)練,盡量避免顏色空間轉(zhuǎn)換; 2) 使用FFMPEG解碼,并輸出YUV格式,使用CUDA把YUV格式轉(zhuǎn)換為BGR,同時還進行進行標(biāo)準(zhǔn)化、BGRBGRBGR轉(zhuǎn)為BBBGGGRRR等推理常有操作。實現(xiàn)多個步驟合并為一個cuda核,降低數(shù)據(jù)流轉(zhuǎn),提升吞吐量。例如yolov5,則可以把Focus也合并到一個cuda核中。如果需要中心對齊等操作,依舊可以把仿射變換矩陣傳入到cuda核中,一次完成整個預(yù)處理流程。 下圖為同時實現(xiàn)歸一化、focus、bgr到rgb、bgrbgrbgr轉(zhuǎn)bbbgggrrr共4個操作。
b. 僅考慮CPU解碼,使用FFMPEG可以配合nasm編譯(--enable_asm)支持CPU的SIMD流指令集(SSE、AVX、MMX),比默認(rèn)VideoCapture配置的ffmpeg性能更好。同時還可以根據(jù)需要配置解碼所使用的線程數(shù),控制sws_scale、decode的消耗。
編碼而言,ffmpeg可以使用preset=veryfast實現(xiàn)更高的速度提升于VideoWriter,設(shè)置合理的gop_size、bit_rate可以實現(xiàn)更加高效的編碼速度、更小的編碼后文件、以及更快的解碼速度。
c. NVDEC是一個基于CUDA的GPU硬件解碼器庫,CUVID(NVENC)是編碼庫。
地址是:https://developer.nvidia.com/nvidia-video-codec-sdk
對于ffmpeg配合NVDEC時,需要修改libavutil/hwcontext_cuda.c:356 對于hwctx->cuda_ctx 的創(chuàng)建不能放到ffmpeg內(nèi)部進行管理。這對于大規(guī)模(例如超過32路同時創(chuàng)建解碼器時)是個災(zāi)難。硬件解碼的一個核心就是CUcontext的管理,CUcontext應(yīng)該在線程池的一個線程上下文中全局存在一個,而不是重復(fù)創(chuàng)建。TensorRT的模型加載時(cudaStreamCreate時),會在上下文中創(chuàng)建CUcontext,直接與其公用一個context即可。
對于沒有合理管理CUcontext的,異步獲取ffmpeg的輸出數(shù)據(jù)會存在異常并且難以排查。如果大規(guī)模同時創(chuàng)建32個解碼器,則同時執(zhí)行的程序,其前后最大時長差為32秒。并且由于占用GPU顯存,導(dǎo)致程序穩(wěn)定性差,極其容易出現(xiàn)OOM。
frames_ctx->format指定為AV_PIX_FMT_CUDA后,解碼出的圖像數(shù)據(jù)直接在GPU顯存上,格式是YUV_NV12,可以直接在顯卡上對接后續(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進行,避免使用VideoCapture/VideoWriter;
b) GPU編解碼,服務(wù)器使用配置了NVDEC的ffmpeg進行,嵌入式使用DeepStream(不支持NVDEC);
c) 避免使用cvtColor,盡量合并為一個cuda kernel減少數(shù)據(jù)扭轉(zhuǎn)實現(xiàn)多重功能。
CUDA/TensorRT
關(guān)于推理的一些優(yōu)化
a. 對于圖像預(yù)處理部分,通常有居中對齊操作:把圖像等比縮放后,圖像中心移動到目標(biāo)中心。通??梢允褂胷esize+ROI復(fù)制實現(xiàn),也可以使用copyMakeBorder等CPU操作。
在這里推薦采用GPU的warpAffine來替代resize+坐標(biāo)運算。原因是warpAffine可以達到一樣效果,并且代碼邏輯簡單,而且更加容易實現(xiàn)框坐標(biāo)反算回圖像尺度。對于反變換,計算warpAffine矩陣的逆矩陣即可(使用invertAffineTransform)。GPU的warpAffine實現(xiàn),也僅僅只需要實現(xiàn)雙線性插值即可。
b. 注意計算的密集性問題。
cudaStream的使用,將圖像預(yù)處理、模型推理、后處理全部加入到同一個cudaStream中,使得計算密集性增加。實現(xiàn)更好的計算效率,統(tǒng)一的流進行管理。所有的GPU操作均采用Async異步,并盡可能減少主機到顯存復(fù)制的情況發(fā)生。方案是定義MemoryManager類型,實現(xiàn)自動內(nèi)存管理,在需要GPU內(nèi)存時檢查GPU是否是最新來決定是否發(fā)生復(fù)制操作。取自caffe的blob類。
c. 檢測器通常遇到的sigmoid操作,是一個可以加速的地方。
例如通常onnx導(dǎo)出后會增加一個sigmoid節(jié)點,對數(shù)據(jù)進行sigmoid變?yōu)楦怕屎筮M行后處理得到結(jié)果。Yolov5為例,我們有BxHxWx [(num_classes + 5) * num_anchor]個通道需要做sigmoid,假設(shè)B=8,H=80,W=80,num_classes=80,num_anchor=3,則我們有8x80x80x255個數(shù)字需要進行sigmoid。而真實情況是,我們僅僅只需要保留confidence > threshold的框需要保留。而大于threshold的框一般是很小的比例,例如200個以內(nèi)。真正需要計算sigmoid的其實只有最多200個。這之間相差65280倍。這個問題適用全部存在類似需求的檢測器后處理上。 解決對策為,實現(xiàn)cuda核時,使用desigmoid threshold為閾值過濾掉絕大部分不滿足條件的框,僅對滿足的少量框進行后續(xù)計算。
d. 在cuda核中,避免使用例如1.0,應(yīng)該使用1.0f。
因為1.0是雙精度浮點數(shù),這會導(dǎo)致這個核的計算使用了雙精度計算。眾所周知,雙精度性能遠低于單精度,更低于半精度。
線程池Thread Pool
主要利用了c++11提供的condition_variable、promise、 future、mutex、queue、thread實現(xiàn)。線程池是整個系統(tǒng)的基本單元,由于線程池的存在,輕易實現(xiàn)模型推理的高度并行化異步化。
使用線程池后,任務(wù)通過 commit提交,推理時序圖為:
當(dāng)線程池配合硬件解碼后,時序圖為:
此時實現(xiàn)了GPU運算的連續(xù)化,異步化。GPU與CPU之間沒有等待。
資源管理的RAII機制
Resource Acquisition Is Initialization
在C++中,使用RAII機制封裝后,具有頭文件干凈,依賴簡單,管理容易等好處。
其要點在于:第一,資源創(chuàng)建即初始化,創(chuàng)建失敗返回空指針;第二,使用shared_ptr自動內(nèi)存管理,避免丑陋的create、release,new、delete等操作;第三,使用接口模式,hpp聲明,cpp實現(xiàn),隱藏細節(jié)。外界只需要看到必要的部分,不需要知道細節(jié)。
頭文件:interface.hpp
實現(xiàn)文件:interface.cpp
責(zé)任編輯:lq
-
gpu
+關(guān)注
關(guān)注
27文章
4591瀏覽量
128144 -
編解碼器
+關(guān)注
關(guān)注
0文章
234瀏覽量
24135 -
流媒體
+關(guān)注
關(guān)注
1文章
191瀏覽量
16630
原文標(biāo)題:實戰(zhàn) | 硬編解碼技術(shù)的AI應(yīng)用
文章出處:【微信號:kmdian,微信公眾號:深蘭科技】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論