監控視頻的柔性實時分析架構

李 剛,張 晴,徐傳運,2,徐 昊,宋志瑤

(1.重慶理工大學 兩江人工智能學院, 重慶 401331;2.重慶師范大學 計算機與信息科學學院, 重慶 401331)

0 引言

隨著計算機視覺與人工智能的發展,監控攝像機內嵌了越來越多的視頻分析算法,能夠獨立實現人臉檢測、人數統計等操作,但這種攝像機價格比較昂貴,且使用不夠靈活。其主要問題有:攝像機在單個預置點上可以添加一個算法工作,當然一個固定位置可以添加多個預置點,達成了在固定位置設置多個算法的目的,但缺少移動過程中的檢測,或移動后點位的相同算法檢測,需要重復登錄攝像機設置預置點,操作比較繁瑣,當攝像機數量達到一定程度后無疑是一種災難。攝像機功能固定,內嵌的算法較少,不利于擴充,對視頻內容的檢測率較低,大量的視頻內容因缺少對應的智能算法而不能及時檢測異常內容。

另一方面,不少文獻提出并構建了智能視頻分析系統,目前關于視頻監控遠程視頻分析主要有2種實現架構,分別是基于邊緣計算和云計算的架構[1-2]。隨著研究的進展,國內[3-6]與國外[7-11]學者相繼開發出來很多的智能視頻監控系統,其中也提出若干對應不同場景的架構。例如,陳曦[3]、Xing[4]、張陽[5]與朱愛娟[6]等對智能視頻分析系統中的關鍵技術做了詳細的介紹。Tandayya教授團隊開發的Nokkhum視頻監控服務系統[7-9,12]具有一定的靈活性和可拓展性。Billones等[13]在檢測交通違規上提出了一種靈活的多層架構。Chen等[14]提出將深度學習用于邊緣計算的架構。謝瑩[15]提出基于Web的插件播放架構。Ibrahim等[16]對當前神經網絡算法用于視頻分析做了總結。Jang等[17-18]提出基于邊緣計算的視頻架構。

以上系統的設計大都基于單個算法或一組對應相關場景的算法,這些系統中有能夠復用視頻數據的設計,但缺乏對算法性能和精度的衡量,系統柔性較差。每種算法只有一個版本,一旦出現任務量激增、計算資源短缺或其他故障,這些系統的性能就將出現斷崖式下降,且不能主動探測視頻內容、動態加載算法,缺乏靈活性。

通過對各個系統架構的研究,提出一種通用的柔性監控視頻實時分析架構FRTA(flexible real-time analysis)。FRTA的柔性體現在:

1) 計算流程可定義,可分級,自動調整分配計算資源,超參數可調整。

2) 統一管理視頻流數據與文本數據,減少圖片的復制和網絡傳輸,在不刪減信息的同時減少系統內部通信的數據大小。

3) 把算法抽象成隨插隨用并能相互組合的組件,視頻、圖片和文本數據能與算法任意結合,且能夠解耦合。

4) 保持視頻幀序列的順序輸入輸出的同時做無序計算。

1 FRTA架構

對于視頻監控來說,實時的分析處理無疑會產生更大的好處,能夠提高視頻分析質量,一般從以下幾方面著手:提高分析算法的精度,縮短算法的執行時間,增加檢測幀數和檢測分析算法的數量,以應對不同的場景需求。

FRTA架構是主要從控制檢測幀數和檢測算法數兩方面設計的一種柔性實時視頻智能分析架構。其架構柔性體現在:檢測幀數、檢測算法數、檢測算法版本和檢測數據都可控。FRTA可根據用戶需求和系統資源自動調控視頻分析的算法數量、算法版本、圖片分辨率大小、視頻幀數等。當系統任務需占用過多系統資源時,架構自動調解系統后臺任務執行,釋放資源用于實時任務;當系統出現資源閑置時,架構會主動開始一些預設任務,對視頻內容進行分析。

FRTA最重要的目的是為了實現監控視頻流全面的實時分析,即在不影響視頻監控實時性和清晰度的同時,對視頻流做更多的檢測分析,脫離人工并自動挖掘更多細節,最終能夠把異常情況及時反饋給視頻監控使用人員。

FRTA架構中有5個主要模塊:算法管理器、任務定義器、調度器、算法執行器以及數據管理模塊——黑板,如圖1所示。

圖1 FRTA架構主要模塊

采用上述設計的原因主要有:

1) 滿足單一職責,避免模塊之間過度耦合。

2) 實現流的柔性處理,避免一個算法拉一路流,做生硬粗暴的計算。

3) 實現接口與實現分離,每個模塊可以根據自己的需要實現對應的接口,以適應不同的應用場景和計算方式。

4) 保證算法的隨插隨用,即算法可以固定在某臺機器上運行,也可以動態腳本啟動,同時一路流的關閉不影響算法的繼續運行,只要還有流需要,這些算法就不必重新加載算法,減少時間開銷。

5) 保持視頻流的順序性,視頻流從攝像頭中是按時序被拉取出來的,中間經過一系列的處理后,最終將結果匯總并按時序保存或推送給用戶觀看。處理流程如圖2所示。

圖2 FRTA架構處理流程

以下分別對FRTA架構中5個主要模塊的設計原理和內部工作方案做出詳細說明,并對FRTA工作流程給出歸納和進一步的拓展說明。

1.1 算法管理器

根據算法的來源、類型和作用不同,算法之間除了邏輯之外存在著一些差異性。一些算法來自已經開發好的框架,例如OpenCV;一些算法來自用戶自己訓練的模型,或者是用戶選擇使用某些云平臺提供的模型。算法也有類型上的區分,算法可能是常規的邏輯處理算法,也可能是機器學習或者深度學習算法,常規算法可能對GPU要求不高,但后者在不同CPU上的表現差異性不容忽略。此外,算法的效果也有差別,一個精度特別高的算法可能需要花費更長的時間,而精度差的算法也是可以滿足一般需求的。

因此,算法管理器按照算法的來源、類型、作用、運行效率和條件等對算法進行統一的接口管理,能夠適應多線程和順序執行,并根據用戶能夠提供的設備自動適配,選擇合適的算法以提供差級服務。算法管理器根據算法簽名管理算法,算法簽名由算法名稱和版本號構成,且是唯一的,用戶在注冊算法時會有唯一性檢查。相同功能的算法使用同一個名字,但它們的版本號不同,用以區分彼此。

此外,算法需要說明其輸入和輸出要求,因為所提架構面向的是視頻流處理,所以對輸入為非圖像或視頻幀序列的算法不做考慮。在算法輸入方面,會有圖片顏色空間、寬度、高度、步長、位深等的區別。在算法輸出方面,由于算法來源不同,因此需要做不同的處理:對于架構實現時嵌入的算法,可以直接輸出文本信息;對于輸出圖片或者視頻的第三方應用可以進行標記,或對原始視頻幀做替換等操作。架構中的算法管理器更多的是維持算法的存在,對于算法的輸入輸出需要其他模塊作對應的調整。

為了算法的執行不被機器限制,架構中所有的算法都被調整到無狀態。雖然有些算法在邏輯上具有先后順序,但其實對圖像的要求不會出現一致的情況。同時,為了圖片或者視頻能被盡可能地復用,不能對圖片本身進行修改,除非該圖片只有當前算法使用。算法中的所有數據都被存入黑板,所有的算法都到黑板中拿數據。

1.2 數據管理

為了增加視頻實時分析的維度和多路視頻的聯動,采用集中管理的方式管理所有的數據。架構中最主要的數據便是視頻流,此外還有算法對視頻處理結果的文本數據。架構為所有數據提供統一的基類,方便數據的傳遞和擴展。

算法在處理完一張圖片或一份視頻幀序列后,需要把處理結果緩存起來,以便于后續算法使用。多個算法同時處理一份數據,其完成時間必不相同,因此也需要把先完成任務產生的數據緩存起來,以便于釋放資源用于處理其他的任務。所以在所提架構中采用黑板模式做數據的緩存。

黑板模式有4個基本的角色:數據、數據生產者、數據消費者以及控制器。其中數據便是此架構中的視頻流信息,視頻流對應的幀序列,算法產生的結果,以及最終處理完成的視頻幀序列;數據生產者和數據消費者的角色是可以互換的,生產者也可能使用另一個生產者產生的數據,從而變成了消費者,同樣的消費者產生的數據放入黑板進而成為生產者,因此在架構中將所有的生產者和消費者都統一成任務;控制器控制數據和算法之間的交互,在所提架構中將此部分功能合并到調度器中。

另外,黑板的數據緩存形式可以由架構實現者選擇,其可以選擇自己實現數據緩存,也可以選擇使用數據庫或者消息隊列框架代替。黑板為了方便管理,避免架構過于復雜,根據流的唯一標識劃分隊列,為每一路流在源流、中間和最終數據階段各分配一個隊列。

1.2.1視頻源流數據的處理

首先是對視頻數據的處理,把所有接入系統的攝像頭進行統一管理。在所提架構中,每一個攝像頭只會被拉取一路流。雖然現在的高清攝像頭能支持幾十路流的同時拉取,但同時拉取過多的視頻流會對網絡帶寬和計算機內存提出更大的挑戰。同時,在做算法分析時也會產生重復處理的操作,這同樣會造成計算資源的浪費。因此所提架構采取一路攝像頭只拉取一路視頻流的方案。

對所有的視頻流進行統一的管理,為每一路流維持一份類似于文件管理中的文件控制塊的元信息。這些信息包含視頻流的來源(攝像頭的相關信息與攝像頭所屬單位等信息),視頻的封裝格式、編碼器、解碼器、幀分辨率、碼率、幀率、拉流地址、推流地址、拉流器和推流器等信息。同時為了能夠保證系統各模塊間的通信壓力,為每一路流分配一個唯一標識。

每一路流在系統中緩存一份幀序列,這是從攝像頭中拉取的視頻幀序列。視頻中的每一幀圖片從攝像頭抓取出來時會帶有大量的信息,但只有一些與圖片相關的信息是在幀序列或者圖片處理的時候常用的,例如圖片的寬和高、圖片片素格式、圖片步長、圖片深度等。在圖片復制或者傳送時,只傳輸這些必要的信息無疑會減少帶寬的花銷,同時為每一幀圖片分配一個流內唯一標識,作為圖片所屬流的位置。

一路流的視頻幀不可能完全都緩存在內存中:一方面,前面的幀已經被處理過了,沒有被緩存的必要了;另一方面,拉流器還在不停地從攝像頭中抓取視頻幀,這些視頻幀不及時被緩存可能會阻塞后續的視頻幀抓取,還會影響視頻流的處理流程,使視頻的實時播放出現卡頓、丟幀等現象,甚至會造成內存溢出的錯誤。所以處理過的視頻幀需要及時保存。

1.2.2中間數據處理

中間數據是除了最初的視頻流和最終數據外算法產生的結果,之所以將算法產生的結果獨立出來,也是根據單一職責的原則,將不同時期的數據放到不同的地方,便于管理和維護。在源流隊列中有視頻幀時,架構便將視頻幀出列,放入中間數據隊列中,等待該幀上所有的任務做完。調度器檢測到該幀上的任務沒有完成,便會繼續等待任務執行或者將未執行的任務交給算法執行器,已完成任務的結果則將寫入該幀關聯的集合中。當該幀上的所有任務都已完成或者超時,該幀會從中間數據隊列中出列,放入最終數據隊列中。

1.2.3最終數據處理

最終數據由原始視頻幀序列和對應的文本數據組成,其表示該視頻幀已被處理完成,所有的數據都需要按照原始視頻幀的時序排列。

一般情況下拉流視頻的幀率為25幀/s,2幀時間間隔為40 ms,考慮到無處理流的時間消耗,在所提架構中設置初始30 ms的等待時間,即推流器或者數據保存的等待最大時長為30 ms,如果當前隊列中最小視頻幀不是已推送視頻幀的下一幀,那么直接推送此幀,而不再等待。

FRTA提供可設置的等待時長,用戶可手動或者由系統自動調整適當的等待時長,調整策略為監測視頻幀上的任務完成時間、任務生成和調度花費時間。一般在推送實時流給用戶觀看時需要調整等待時長來保證視頻的流暢度,因此一幀圖片的處理總時間不應超過40 ms或幀間隔時間,在調度中還有一些策略來保證視頻的流暢度。

1.3 任務定義

任務定義器主要管理視頻流和算法之間的關系,視頻流和算法存在一對一、一對多、多對一或者多對多的關系。任務定義器便是根據視頻流和算法之間的設定來維持一個最優的對應關系,以便減少重復計算次數和數據內存占用量。任務定義流程如圖3所示。

圖3 任務定義流程

1.3.1用戶事件

用戶在前端設定一路視頻流上所綁定的事件,這里的事件為用戶想要在視頻流中觸發的事件,所有的事件都會將用戶、攝像頭、視頻流和算法等信息保存在用戶事件管理器中。經過任務解析器解析后,事件會變成一個個任務,并與視頻流綁定,寫入任務定義器中。

1.3.2任務定義器

任務定義器采用有向無環圖的形式關聯任務的關系,任務之間存在同級和先后的關系。在所提架構中,將所有的最小處理單元都抽象為任務,每一個任務都具有一個任務清單,在清單中包含3個內容:需要算法處理的數據引用、當前算法、算法的輸入要求、算法輸出處理等。關于視頻處理算法或者圖片算法幾乎全是要求輸入的數據是圖片,因此不考慮非圖片或者非視頻幀序列的情況。

一路視頻流綁定的算法大部分是可以同時進行計算的,這種算法處理起來比較簡單,只要計算資源允許,就可以并發或并行執行,先后順序不會影響最后的結果。但有些算法處理需要一些前置算法,其原因有很多,例如用戶設定的事件具有先后順序。另外,有些算法比較耗時,或者視頻變化比較少,這些情況下對每一幀都處理,無疑是一種不可行或者非必要的計算。因此采用一些聚焦算法感知原始視頻幀的內容變化,之后對視頻幀做縮放或者分割等處理,最后把滿足算法輸入需求的圖片地址傳給算法,這樣處理會節約大量的計算資源,并能進一步保障視頻的實時性。

任務定義器的另一個主要作用便是可以根據算法的輸入輸出主動推導算法的前置算法和輸出結果的處理方式。例如,如果算法要求的輸入是灰度圖片,任務定義器便會檢測當前圖片是否為灰度圖,如果不是便會自動調用圖像像素轉換算法,將彩色圖片轉換成灰度圖。

1.3.3任務工廠

根據任務中的算法生成對應的算法對象或加載對應算法的模型。通過工廠模式,不僅可以不暴露創建邏輯的創建任務所需的算法對象,而且可以對算法的對象進行管理。加載算法模型需要花費一定的時間,如果在每次使用算法時都加載一個新的模型并創建一個新的對象,那么必然浪費很多不必要的時間,因此花費很少內存緩存一些還會被用到的算法模型是一件很值得的事。

1.4 調度器

調度器是所有任務執行和數據流動的中間調度者,根據單一職能的原則,把可執行任務和數據流向單獨提取出來,以此控制整個架構中每個任務執行與否、執行時間和執行異常處理等。

調度器從任務定義器中獲取可執行任務,判斷此任務的可執行性,如果不可以執行,那么判斷不可執行的原因,根據原因不同做不同的處理;如果可執行,那么調用算法執行器,若算法執行器回應可執行,則交給算法執行器執行任務,否則做進一步處理。調度器會將算法產生的結果放入黑板的中間數據隊列中,如果當前算法是當前視頻幀唯一一個任務或最后一個任務,那么將算法結果和當前視頻幀放入最終數據隊列中。如果當前算法不是當前視頻幀唯一一個任務或最后一個任務,那么檢測黑板中有沒有對應視頻幀:沒有,則將視頻幀放入隊列中,然后將該算法輸出結果放入對應視頻幀的結果集合中,同時檢測該視頻幀的任務有沒有全部執行完或者有沒有任務超時;有,則將該幀放入最終數據隊列中。調度器工作流程如圖4所示。

圖4 調度器工作流程

調度器另一方面的工作便是對整個系統的管理,當一路流收到停止分析指令,或者拉流出現問題、推流和保存視頻出現異常等情況時,調度器便會向各個模塊發出對應的指令,關閉一些不需要的算法對象,清空對應數據內存,做出通知系統處理結果等操作。

1.5 算法執行器

之所以把算法執行器單獨提取出來,是為了將所有的計算資源進行統一的管理和分配,這種設計不僅支持單機資源管理,還支持分布式或者云計算的方式。也就是說,架構不需要關心是誰在執行任務,只需要調度器將任務交給算法執行器便可以等待一個執行結果。

所有的來自調度器的任務都會被視為一個基本任務執行單元,算法執行器根據任務清單獲取任務中的算法和數據,執行系統負責算法的調用和執行,并將結果返送給算法執行器;算法執行器根據任務清單中的結果處理方式處理結果,并將算法結果返送給調度器。

1.6 FRTA工作流程

FRTA架構的整個處理流程為:

1) 整個架構從用戶設置攝像頭上的事件開始,用戶事件會被保存在用戶事件管理器中,然后經過任務解析器解析成任務集合,這些任務在任務定義器中與視頻流綁定。

2) 任務定義器檢測根據調度器的請求和任務完成情況,同時根據當前所要執行的算法,從算法管理器中拿到算法簽名和算法路徑。根據算法的輸入需求檢測當前數據是否符合算法要求,不符合就自動推到合適的處理算法,再到任務工廠加載算法模型生成算法對象,然后把算法和數據繪制成任務清單,將任務清單傳給調度器。

3) 調度器拿到任務清單后,根據清單中數據和算法查看是否需要算法執行器執行。如果不需要執行,那么直接將數據放入最終隊列中;如果需要執行,那么將最初的視頻幀放入黑板中間隊列中,然后調用算法執行器執行任務。

4) 算法執行器會根據整個系統的資源情況分配計算資源,在執行完畢后將結果返回給調度器。調度器檢測對應視頻幀的任務是否執行完畢:如果執行完畢,那么將該視頻幀和相關的處理結果寫入最終數據隊列,轉到步驟5),否則向任務定義器請求下一各任務,重復步驟2)—4)。

5) 當黑板中最終數據隊列出現數據時,便會開始推流或者保存數據的操作。如果推流就根據推流用戶指定的推流策略與等待策略開始工作。無論推流還是保存數據都被規劃為任務,由算法執行器執行。

架構通過文本數據標記圖片或視頻數據,減少計算機復制造成的時間開銷和內存開銷,同時對任務超時、拉流中斷、推流異常和任務獲取異常等情況做出處理。

1.7 FRTA對比分析

與TANDAYYA教授[7-9,12]領導設計的Nokkhum系統相比,FRTA在視頻內存存儲上更加靈活。Nokkhum系統視頻流直接對應視頻分析算法的設計,無法做到視頻片段甚至視頻任意幀上的算法組合。FRTA更能做到靈活的組件插拔,不用停掉整個視頻流,可以在任意時間點設置任意時間段內的算法,算法可配置,動態組合,具有事件重要優先級,更具靈活性。

與BERAN[11]設計的可選分析算法視頻分析系統相比,FRTA的算法不僅可選,而且可配置。分析算法不僅來自代碼集成的算法,還支持系統管理人員將按照FRTA規則配置好的算法加入系統中,這樣算法的維護工作會更輕松,系統的靈活性和可用性也更高。

另外,為了降低延遲,減輕服務器計算壓力,很多人的研究方法轉向邊緣計算[2,4,17-18],FRTA架構與邊緣計算并不沖突,反而是對邊緣計算的補充。從宏觀上抽象視頻流和算法,形成一個個計算任務,便于邊緣計算更集中于核心任務的處理。例如先做視頻流內容的感知分析,然后將可能有任務的視頻幀序列分發給對應的處理單元,這樣可以更高效地利用算力,減少無用視頻幀序列流向計算單元。從宏觀上把整個架構內的計算單元專業化,甚至可以動態地分配算法到整個邊緣計算網絡中,避免出現某些邊緣設備長時間閑置,而其他的邊緣設備卻處理不完任務的情況。

綜上所述,FRAT的優勢在于更靈活的架構設計,能夠動態配置算法,并做到熱插拔,算法優先級分配;更高的系統利用率,避免算法占據服務器卻沒有工作任務分配的情況發生。

2 結論

介紹了一種柔性的實時視頻分析架構FRTA,此架構可以根據系統任務和系統資源自動調控分析算法的數量、算法版本、數據量等;根據用戶需求和系統資源自動調控視頻分析的算法數量、算法版本、圖片分辨率大小、視頻幀數等。當系統任務需占用過多系統資源時,架構自動調解系統后臺任務執行,釋放資源用于實時任務;當系統出現資源閑置時,架構會主動開始一些預設任務,對視頻內容進行分析。

FRTA架構采用單一職責的設計原則,將整個系統分為任務定義器、數據管理、算法管理、調度器、算法執行器等模塊,從較高層次抽象設計系統架構,從而提出一種多路視頻實時分析的系統架構。該架構能靈活地保證用戶任務的執行,并能夠更詳細、更主動地分析全場景內容;系統內部大幅度減少重復數據的內存占用,增加視頻內容分析的準確度,提高系統的可擴展性和適用性。

FRTA架構實現了更靈活的架構模塊組合,可由架構實現者根據需要實現各個模塊,保證了架構的計算效率和計算模式的多樣性,增加了智能監控系統的擴展性。