基于嵌入式邊緣設備的端-邊-云視頻流分析系統構建*

朱錦輝

（中國人民解放軍91404部隊 秦皇島 066001）

1 引言

近幾年來，卷積神經網絡的崛起推動著視頻流分析應用快速發展，并造就了高效率、高準確度的視頻流分析水準。監控攝像頭被廣泛部署，如部署于商場中、街道上、無人機機身上等。隨著應用范圍的不斷擴大，對視頻流分析的要求也越來越高［1～3］。特別是在智慧軍營中，要求同時對大范圍內的大量視頻流進行分析，并且需要及時、準確地得到分析反饋。針對以上問題，本文設計了一項端-邊-云計算架構之上的兼顧邊-云間數據傳輸時延和邊緣節點硬件資源受限特性的視頻流分析任務調度策略 VideoEmbedded［4～7］，根據視頻流分析請求的特性來進行任務調度，在保證推理準確度的前提下，提高視頻流分析的實時性，降低整體系統資源占用。同時，本文設計了一套基于Docker容器技術、K8s（Kubernetes）容器編排技術的端-邊-云視頻流分析系統，其具有良好彈性伸縮能力和自動化運營能力。

2 端-邊-云視頻流分析系統構建

在端-邊-云計算架構中［8～10］，智能服務（如車輛檢測、車色識別等）可部署于邊緣節點和云節點上。邊緣節點的優勢是其與移動設備更近，且它們間具有更低的數據傳輸延遲和更大的帶寬。在一般負載情況下，視頻流分析應用的連續性是比較好保證的（實現足夠多的并行化），而應用的實時性更受任務調度的影響，故本文提出的VideoEmbedded任務調度策略將以實時性為最優化目標。

VideoEdge在第二階段進行請求合并，即對智能服務進行復用。而VideoEmbedded是一階段的，即一開始就對智能服務進行復用。以視頻流車輛信息分析為例（分析任務包括車輛檢測、車色識別、車牌檢測和車牌識別），表1列舉出了與一個請求Qi相關的符號表示。

表1 與請求i相關的符號表示

所以VideoEmbedded對智能服務復用的約束可表示為式（1）～（6）。

需要求的最優項為（實時性優先）式（7）。

上述的最優解問題是一個NP難問題，假設有m個請求，各智能服務有n種不同準確度的智能模型可選，則暴力求解該問題的時間復雜度為O（（m·（m-1）…1）n3）。為降低求解時間復雜度，下面根據不同請求的不同特性來將該問題簡化以求一較優解。

視頻流分析的輸出結果一般有兩種［11～13］：

1）輸出結果仍為視頻流，與原視頻流相比，輸出的視頻流可能在編碼方式、色域、分辨率、幀率等方面發生改變，并且往往是帶有智能信息的。

2）輸出結果為智能信息結構化數據，即將在智能分析過程中所得的智能信息存儲起來。

對于這兩種不同的輸出結果，做不同的考慮：

1）輸出結果仍為視頻流的請求，其特點是需要對輸入視頻流進行逐幀智能分析，且最終輸出的視頻流還是要傳輸到云上去的，因為用戶是通過云來獲取輸出視頻流的。故對這種請求應該將任務優先遷移至云上執行，因為這樣做能夠節省邊緣資源。

2）輸出結果為智能信息結構化數據的請求，其特點是需要對輸入視頻流進行抽幀智能分析，同時要傳輸到云上去的智能信息結構化數據相比于視頻流要小得多。故對這種請求應該將任務優先遷移至邊緣節點上執行，因為這樣做能夠節省邊-云間帶寬。

系統整體架構設計將邊緣分為多個區域，每個區域都會部署一些Worker節點，在Worker節點之上可以按需部署智能服務和其它服務。同樣在云上也會部署Worker節點，這些Worker節點由云上的Master節點統一管理。將所有服務程序都置于Docker容器中運行，啟用多個K8s Master熱備份節點，在多個K8s Master節點之上，使用keepalived工具來向外提供虛擬Socket（IP：Port），并使用haproxy工具來保證多個K8s Master節點間的負載均衡，從而使K8s集群具有較高的可靠性。

對于每個K8s Pod，其只擁有一個Docker容器。圖1使用Deployment控制器來部署智能服務、頁面前端等無狀態的服務；使用StatefulSet控制器來部署MySQL數據庫、Kafka消息隊列等有狀態的服務。在服務發現方面，使用ClusterIP類型的Service來在集群內部暴露Pod服務，使用NodePort類型的Service來向集群外部暴露Pod服務。

圖1 服務部署

用戶通過Web前端來發起視頻流實時智能分析請求，也可以發起對輸出視頻流或智能信息結構化數據的檢索等請求，在圖2示例中，在最大化智能服務和邏輯進程中接入視頻流以對其進行智能分析，將智能信息結構化數據的輸出結果發布至Kafka消息隊列，對于攜帶智能信息的視頻流輸出結果，將其推給Nginx RTMP服務器。

圖2 任務調度

3 對比實驗

3.1 實驗設計

如圖3所示，實驗中使用兩臺Atlas200DK組成一個邊緣區域，使用6臺服務器組成一個私有云（其中代理服務器位于K8s集群之外）。

圖3 實驗環境

如表2，在智能組件中使用到6種模型——4種檢測模型和兩種分類模型，對于車牌識別，使用HyperLPR；對于對象跟蹤（只在輸出結果為視頻流時啟用），使用Kalman。為方便闡述，我們分別將準確度和體積分為4個等級（A、B、C和D，準確度遞減，體積遞增），并給每臺Atlas200DK分配8個槽位（以第2節實驗結果為依據），給每張顯卡分配20個槽位（以500 MB顯存為一槽位，每張顯卡預留1～2 GB顯存）。為保證應用的連續性，限制Atlas200DK、Worker01、Worker02和Worker03上的可使用線程數分別為7、20、20和32（云服務器的CPU主頻更高）。對于VideoEdge中的主資源需求（Dominant Resource Demand），僅考慮主要的帶寬（邊-云間帶寬以恒定的90.5 Mbits/s來計算，在服務部署時保證負載均衡（以一臺設備上的資源占用百分比為依據，先優先槽位占用的均衡，其次是線程占用）。

表2 智能組件中使用到的模型

如表3，共設計了3組視頻流實時智能分析請求，其中每個請求都需要進行所有的智能分析（車輛檢測、車牌檢測、車牌識別、車色識別）。若輸出結果為視頻流，則請求的處理幀率為25 FPS，對所有智能組件準確度的要求皆為B；否則請求的處理幀率為1 FPS，針對智能組件準確度的要求，又需進行三組不同的實驗：所有要求皆為B（組合1）、所有要求皆為D（組合2）、分別在720P和1080P請求中一半要求為D一半要求為B（組合3）。實驗中的輸入視頻流幀率為25 FPS，分辨率為1080P/720P，編碼方式為H.264 NV12，其中大部分的幀中只包含1個車輛對象，最多包含兩個車輛對象，且輸入視頻流通過FFmpeg+EasyDarwin對MP4視頻文件推流產生。為方便對比，在VideoEdge中，請求的處理順序為：先處理輸出結果為視頻流的請求，然后按照輸入視頻流分辨率由高到低和準確度要求由高到低的順序依次處理剩余請求。量化A級別準確度為4，C級別準確度為2。在實時性的度量方面，量化邊緣節點間和云節點間的數據傳輸時延皆為1，邊緣節點與云節點間的數據傳輸時延為300。對于分辨率為的視頻流，假設H.264壓縮比為20：1，則可量化其帶寬占用為

表3 視頻流實時智能分析請求

對于智能信息結構化數據，量化其帶寬占用為

3.2 實驗結果與分析

如圖4，VideoEdge以整體準確度為最優化目標，在整體準確度方面VideoEmbedded幾乎與之持平。因為VideoEmbedded更傾向于使用輕量級智能模型，所以對于組合2這樣的請求，會優先選用輕量級智能模型，從而導致整體準確度稍有下降。同時，這也能夠節省一定的系統資源（見圖5中的組合2對比）。如圖5，VideoEmbedded的系統整體資源占用始終少于或等于VideoEdge。VideoEmbedded和VideoEdge都會優先將輸出結果為智能信息結構化數據的智能分析任務調度到邊緣區域執行，在請求數較小的情況下，因為VideoEdge Merge是二階段的，使得有部分任務由于邊緣區域沒有足夠的資源而被分配至云上執行，而Video-Embedded最開始就是從智能組件復用出發的，這使得這些任務可以全部分配至邊緣區域中執行，提高了組件復用率，從而占用更少的系統資源。這也直接導致了相比于VideoEdge，VideoEmbedded可以占用更少的邊-云間帶寬。如圖6，VideoEmbedded能夠更充分地利用邊緣資源，相比于VideoEdge Merge，能夠節省12.99%～38.96%的邊-云間帶寬，且能夠穩定地保證應用整體的高實時性，如圖7，邏輯進程始終與智能服務處于同一區域，在4/9的情況下，VideoEmbedded的整體實時性更高。隨著請求數的不斷增加，即使是使用VideoEmbedded邊緣區域也因資源有限而無法容納更多的任務，使得大部分的任務被分配至云上執行，Video-Embedded和VideoEdge Merge的組件復用率逐漸持平，所占用的系統資源也逐漸持平。

圖4 實驗結果整體準確度對比

圖6 實驗結果邊-云間帶寬占用對比

圖7 實驗結果應用整體實時性對比

4 結語

本文設計了一項端-邊-云計算架構之上的兼顧邊-云間數據傳輸時延和邊緣節點硬件資源受限特性的視頻流分析任務調度策略VideoEmbedded，根據視頻流分析請求的特性來進行任務調度，提高了視頻流分析的實時性，降低整體系統資源占用。實驗證明，相比于VideoEdge，本文提出的VideoEmbedded能更充分地利用邊緣資源，在實時性、系統資源和邊-云間帶寬占用等方面表現更優。同時，本文設計了一套基于Docker容器技術、K8s容器編排技術的端-邊-云視頻流分析系統，其具有良好彈性伸縮能力和自動化運營能力。