互動機制

在章節 3.3 中，介紹了互動式平台的系統架構。然而在此平台下，

我們定義了下列的互動機制，包含遠端即時檔案存取、相機之換手機 制、自動錄影機制。

[遠端即時檔案存取]

圖 3-4-1 傳統式檔案存取

圖 3-4-1 為在傳統的監控系統架構下，影像檔案存取的方式。如圖 所示，監控中心藉由各取像設備收集影像資料，安管人員如要觀看監控 的畫面時，需要直接向監控中心存取影像資料。在此架構下，取像設備、

監控中心、安管人員三者都位於同一場所。

圖 3-4-2 遠端即時檔案存取

然而在我們所佈建的監控平台下，影像檔案的存取方式變的更有彈 性，存取方式如圖 3-4-2 所示。取像設備和監控中心位於 Local site，

安管人員可在 Remote site 執行 Client 端程式，此程式會利用 RTSP 協 定和監控中心(Server)溝通，並透過 RTP、RTCP 處理即時的檔案傳輸，

使安管人員可從 Remote site 存取 local site 的影像資料，達到遠端 存取的功能。

[相機之換手機制]

一般的監控系統架構下，如監控中心掌管多台取像設備時，此時安 管人員需以人工方式設定監控中心 Displayer 的顯示畫面，上述相機切 換機制以圖 3-4-3 呈現：

圖 3-4-3 相機換手機制(traditional)

圖 3-4-3 為傳統式的相機換手機制，displayer 可個別顯示擷取到 的影像 image1~imageN，而 displayer 顯示的影像畫面需由人工設定。

圖 3-4-4 相機換手機制(interactive1)

圖 3-4-4 為互動式的相機換手機制架構，在 Local Site 部分，監 控中心透過取像設備取得影像資料。在 Remote Site 部分，安管人員透 過 Client App 程式執行遠端即時檔案存取的動作。起初，Server 端會 傳送某一預設的相機影像(Image J)透過串流系統傳輸資料到 Client 端。Client 端首先對接收到的資料進行串流系統相關的前置處理，經前 置處理之後可得影像資料，再交給影像處理程式處理，搭配我們事先定 義的相機 Hand off 機制，可決定此時要不要切換相機。如果決定要切 換相機時，此時 Client 端會使用 RTSP 協定所提供的 PING Method，將 所要切換的相機訊息隱藏在此 PING Message 裡，透過 Client 端的 session controller 傳送此 Method 給 Server 端。當 Server 端收到 Client 所傳送的 PING Message 之後，會去解析 PING Message 所內含的 文字訊息，當它發現有切換相機的訊息之後，便會針對 Client 端所要 求的相機影像，傳送此相機影像的 RTP 資料給 Client 端。如此一來，

Client 端便可取得指定的相機影像資料。

圖 3-4-5 相機換手機制(interactive2)

圖 3-4-5 為另一種互動式的相機換手機制，Server 端負責影像資料 的取得，進一步的將收集到的影像資料進行 trans-coding 的動作，接 著透過 Streaming Module 將資料傳輸出去。值得注意的地方為在此處 所 傳 輸 的 影 像 訊 號 並 非 只 有 一 個 相 機 的 影 像 ， 而 是 包 含 多 個 影 像 (Image1~ImageJ)。Client 收到 Streaming data 之後，經由前置處理取 得 RGB 影像，但此時為多個影像訊號，Client 端的 Displayer 顯示的為 多個相機的取像畫面。然而在 Displayer 端呈現多個影像畫面的方式會 造成 Client 端的安管人員要花費很多的心力去監看各畫面的情形，因 此我們改變 displayer 呈現的方式，某一時間點僅呈現一個較重要的相 機取像畫面，使監控人員只需注意一個相機的影像畫面即可。而在眾多 的相機影像畫面裡，如何決定 Displayer 呈現的影像。此時可將多個影 像畫面送到影像處理程式處理，將處理的結果比對事前所定義的相機換 手機制，如此便可以決定要呈現的相機影像。

[錄影機制]

在一般的監控系統架構下，如要進行錄影的動作時，都需要人工設 定，而且所錄影的畫面在很多時間區段可能都是不重要的影像畫面。有 鑑於錄影機制的互動性不足，及錄影檔中不重要的影像片段所造成的儲 存空間浪費，因此我們提出一種互動式的錄影機制解決上述問題，系統 架構如圖 3-4-6:

圖 3-4-6 錄影機制(1)

圖 3-4-6 為互動式錄影機制的系統架構圖，主要分為二部分，分別 為 Server 端及 Client 端。Server 端負責影像資料的取得，進一步的將 收集到的影像資料進行 trans-coding 的動作，接著透過 Streaming Module 將資料傳輸出去。Client 收到 Streaming data 之後，經由前置 處理取得 RGB 影像，然後交由影像處理程式處理。處理之後的結果搭配 事前所定義的＂Event Definition＂，可得知此影像有無符合事件定

義。如事件發生時，Client 端會利用 RTSP 所提供的 PING Method，將 錄 影 訊 息 隱 藏 在 此 PING Message 裡 ， 透 過 Client 端 的 session controller 傳送此 Method 給 Server 端。當 Server 端收到 Client 所傳 送的 PING Message 之後，會去解析 PING Message 所內含的文字訊息，

當它發現有錄影訊息時，會告知 Recording Module 進行錄影的動作。

然而經一段時間後，如 Client 端經影像處理發現事件己結束時，會將 結束錄影訊息隱藏在 PING Message，將此 PING Message 傳給 Server 端，

Server 端收到此訊息便知道事件己結束，可結束錄影的動作，如圖 3-4-7 所示：

圖 3-4-7 錄影機制(2)

由上述的系統架構說明，可知此架構可達到自動錄影的功能，也就 是說有事件發生才錄影。如此一來，可節省錄影檔的儲存空間及達到自 動化的功能。