監(jiān)控視頻的柔性實時分析架構(gòu)

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

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

0 引言

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

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

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

通過對各個系統(tǒng)架構(gòu)的研究,提出一種通用的柔性監(jiān)控視頻實時分析架構(gòu)FRTA(flexible real-time analysis)。FRTA的柔性體現(xiàn)在:

1) 計算流程可定義,可分級,自動調(diào)整分配計算資源,超參數(shù)可調(diào)整。

2) 統(tǒng)一管理視頻流數(shù)據(jù)與文本數(shù)據(jù),減少圖片的復(fù)制和網(wǎng)絡(luò)傳輸,在不刪減信息的同時減少系統(tǒng)內(nèi)部通信的數(shù)據(jù)大小。

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

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

1 FRTA架構(gòu)

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

FRTA架構(gòu)是主要從控制檢測幀數(shù)和檢測算法數(shù)兩方面設(shè)計的一種柔性實時視頻智能分析架構(gòu)。其架構(gòu)柔性體現(xiàn)在:檢測幀數(shù)、檢測算法數(shù)、檢測算法版本和檢測數(shù)據(jù)都可控。FRTA可根據(jù)用戶需求和系統(tǒng)資源自動調(diào)控視頻分析的算法數(shù)量、算法版本、圖片分辨率大小、視頻幀數(shù)等。當(dāng)系統(tǒng)任務(wù)需占用過多系統(tǒng)資源時,架構(gòu)自動調(diào)解系統(tǒng)后臺任務(wù)執(zhí)行,釋放資源用于實時任務(wù);當(dāng)系統(tǒng)出現(xiàn)資源閑置時,架構(gòu)會主動開始一些預(yù)設(shè)任務(wù),對視頻內(nèi)容進行分析。

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

FRTA架構(gòu)中有5個主要模塊:算法管理器、任務(wù)定義器、調(diào)度器、算法執(zhí)行器以及數(shù)據(jù)管理模塊——黑板,如圖1所示。

圖1 FRTA架構(gòu)主要模塊

采用上述設(shè)計的原因主要有:

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

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

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

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

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

圖2 FRTA架構(gòu)處理流程

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

1.1 算法管理器

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

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

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

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

1.2 數(shù)據(jù)管理

為了增加視頻實時分析的維度和多路視頻的聯(lián)動,采用集中管理的方式管理所有的數(shù)據(jù)。架構(gòu)中最主要的數(shù)據(jù)便是視頻流,此外還有算法對視頻處理結(jié)果的文本數(shù)據(jù)。架構(gòu)為所有數(shù)據(jù)提供統(tǒng)一的基類,方便數(shù)據(jù)的傳遞和擴展。

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

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

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

1.2.1視頻源流數(shù)據(jù)的處理

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

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

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

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

1.2.2中間數(shù)據(jù)處理

中間數(shù)據(jù)是除了最初的視頻流和最終數(shù)據(jù)外算法產(chǎn)生的結(jié)果,之所以將算法產(chǎn)生的結(jié)果獨立出來,也是根據(jù)單一職責(zé)的原則,將不同時期的數(shù)據(jù)放到不同的地方,便于管理和維護。在源流隊列中有視頻幀時,架構(gòu)便將視頻幀出列,放入中間數(shù)據(jù)隊列中,等待該幀上所有的任務(wù)做完。調(diào)度器檢測到該幀上的任務(wù)沒有完成,便會繼續(xù)等待任務(wù)執(zhí)行或者將未執(zhí)行的任務(wù)交給算法執(zhí)行器,已完成任務(wù)的結(jié)果則將寫入該幀關(guān)聯(lián)的集合中。當(dāng)該幀上的所有任務(wù)都已完成或者超時,該幀會從中間數(shù)據(jù)隊列中出列,放入最終數(shù)據(jù)隊列中。

1.2.3最終數(shù)據(jù)處理

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

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

FRTA提供可設(shè)置的等待時長,用戶可手動或者由系統(tǒng)自動調(diào)整適當(dāng)?shù)牡却龝r長,調(diào)整策略為監(jiān)測視頻幀上的任務(wù)完成時間、任務(wù)生成和調(diào)度花費時間。一般在推送實時流給用戶觀看時需要調(diào)整等待時長來保證視頻的流暢度,因此一幀圖片的處理總時間不應(yīng)超過40 ms或幀間隔時間,在調(diào)度中還有一些策略來保證視頻的流暢度。

1.3 任務(wù)定義

任務(wù)定義器主要管理視頻流和算法之間的關(guān)系,視頻流和算法存在一對一、一對多、多對一或者多對多的關(guān)系。任務(wù)定義器便是根據(jù)視頻流和算法之間的設(shè)定來維持一個最優(yōu)的對應(yīng)關(guān)系,以便減少重復(fù)計算次數(shù)和數(shù)據(jù)內(nèi)存占用量。任務(wù)定義流程如圖3所示。

圖3 任務(wù)定義流程

1.3.1用戶事件

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

1.3.2任務(wù)定義器

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

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

任務(wù)定義器的另一個主要作用便是可以根據(jù)算法的輸入輸出主動推導(dǎo)算法的前置算法和輸出結(jié)果的處理方式。例如,如果算法要求的輸入是灰度圖片,任務(wù)定義器便會檢測當(dāng)前圖片是否為灰度圖,如果不是便會自動調(diào)用圖像像素轉(zhuǎn)換算法,將彩色圖片轉(zhuǎn)換成灰度圖。

1.3.3任務(wù)工廠

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

1.4 調(diào)度器

調(diào)度器是所有任務(wù)執(zhí)行和數(shù)據(jù)流動的中間調(diào)度者,根據(jù)單一職能的原則,把可執(zhí)行任務(wù)和數(shù)據(jù)流向單獨提取出來,以此控制整個架構(gòu)中每個任務(wù)執(zhí)行與否、執(zhí)行時間和執(zhí)行異常處理等。

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

圖4 調(diào)度器工作流程

調(diào)度器另一方面的工作便是對整個系統(tǒng)的管理,當(dāng)一路流收到停止分析指令,或者拉流出現(xiàn)問題、推流和保存視頻出現(xiàn)異常等情況時,調(diào)度器便會向各個模塊發(fā)出對應(yīng)的指令,關(guān)閉一些不需要的算法對象,清空對應(yīng)數(shù)據(jù)內(nèi)存,做出通知系統(tǒng)處理結(jié)果等操作。

1.5 算法執(zhí)行器

之所以把算法執(zhí)行器單獨提取出來,是為了將所有的計算資源進行統(tǒng)一的管理和分配,這種設(shè)計不僅支持單機資源管理,還支持分布式或者云計算的方式。也就是說,架構(gòu)不需要關(guān)心是誰在執(zhí)行任務(wù),只需要調(diào)度器將任務(wù)交給算法執(zhí)行器便可以等待一個執(zhí)行結(jié)果。

所有的來自調(diào)度器的任務(wù)都會被視為一個基本任務(wù)執(zhí)行單元,算法執(zhí)行器根據(jù)任務(wù)清單獲取任務(wù)中的算法和數(shù)據(jù),執(zhí)行系統(tǒng)負責(zé)算法的調(diào)用和執(zhí)行,并將結(jié)果返送給算法執(zhí)行器;算法執(zhí)行器根據(jù)任務(wù)清單中的結(jié)果處理方式處理結(jié)果,并將算法結(jié)果返送給調(diào)度器。

1.6 FRTA工作流程

FRTA架構(gòu)的整個處理流程為:

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

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

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

4) 算法執(zhí)行器會根據(jù)整個系統(tǒng)的資源情況分配計算資源,在執(zhí)行完畢后將結(jié)果返回給調(diào)度器。調(diào)度器檢測對應(yīng)視頻幀的任務(wù)是否執(zhí)行完畢:如果執(zhí)行完畢,那么將該視頻幀和相關(guān)的處理結(jié)果寫入最終數(shù)據(jù)隊列,轉(zhuǎn)到步驟5),否則向任務(wù)定義器請求下一各任務(wù),重復(fù)步驟2)—4)。

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

架構(gòu)通過文本數(shù)據(jù)標(biāo)記圖片或視頻數(shù)據(jù),減少計算機復(fù)制造成的時間開銷和內(nèi)存開銷,同時對任務(wù)超時、拉流中斷、推流異常和任務(wù)獲取異常等情況做出處理。

1.7 FRTA對比分析

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

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

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

綜上所述,FRAT的優(yōu)勢在于更靈活的架構(gòu)設(shè)計,能夠動態(tài)配置算法,并做到熱插拔,算法優(yōu)先級分配;更高的系統(tǒng)利用率,避免算法占據(jù)服務(wù)器卻沒有工作任務(wù)分配的情況發(fā)生。

2 結(jié)論

介紹了一種柔性的實時視頻分析架構(gòu)FRTA,此架構(gòu)可以根據(jù)系統(tǒng)任務(wù)和系統(tǒng)資源自動調(diào)控分析算法的數(shù)量、算法版本、數(shù)據(jù)量等;根據(jù)用戶需求和系統(tǒng)資源自動調(diào)控視頻分析的算法數(shù)量、算法版本、圖片分辨率大小、視頻幀數(shù)等。當(dāng)系統(tǒng)任務(wù)需占用過多系統(tǒng)資源時,架構(gòu)自動調(diào)解系統(tǒng)后臺任務(wù)執(zhí)行,釋放資源用于實時任務(wù);當(dāng)系統(tǒng)出現(xiàn)資源閑置時,架構(gòu)會主動開始一些預(yù)設(shè)任務(wù),對視頻內(nèi)容進行分析。

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

FRTA架構(gòu)實現(xiàn)了更靈活的架構(gòu)模塊組合,可由架構(gòu)實現(xiàn)者根據(jù)需要實現(xiàn)各個模塊,保證了架構(gòu)的計算效率和計算模式的多樣性,增加了智能監(jiān)控系統(tǒng)的擴展性。