我的「動態」車牌辨識軟體可以辨識來自攝影機或影像檔案「播出」畫面上的車牌，所以三不五時就有客戶問我這個問題；「你的軟體可以辨識『串流』影像嗎？」這個是非題讓我好難回答是或不是？所以乾脆寫篇文章一次說個清楚。

首先大家必須知道：所有影像辨識都只能辨識「影像」，串流是經過壓縮的資料，並不是可以直接辨識的「影像」！必須解碼成單一影像後才能進行辨識，這是電腦顯示卡的預設工作之一，所以執行效率極高，一秒可以解析出60張以上的影像供螢幕顯示，不論來源是攝影機或壓縮過的串流影像檔案過程都是如此。

所以我的動態辨識軟體都是拷貝螢幕上已解碼完成之單一影像作辨識的，單純用程式拷貝螢幕影像，極速大約是每秒三十多張(>30Hz)，但是每一張單一影像辨識完成需要約半秒鐘的時間，如果只是逐張依序辨識，一秒鐘就只能辨識兩三張了！我的軟體是用多執行緒平行運算辨識這些影像的，所以每秒鐘可以達到10-20Hz的辨識頻率！我的動態車牌辨識就是基於這些高速多次的單張影像辨識的結果統計歸納出來的！

因為這些連續的影像中車牌有遠有近，也有各種好辨識到難辨識的角度，所以原始資料中的辨識錯誤率較高，但經過統計，譬如捨棄只出現一兩次的車牌號碼，必須重複三次或以上才予以確認輸出該車牌的資料，這樣最終的辨識率就會蠻高了！即使在複雜的道路多車辨識狀態也可以達到90%以上(通常接近95%)，在停車場的簡單環境則絕對在99%以上。

我很難正確回答上述問題(能否辨識串流？)的原因是：我的軟體是經由上述機制辨識出串流資料中的車牌，但不是直接讀取串流做辨識的！我的軟體必須依賴顯示卡的串流解碼功能才能運作！如果我將「解串流」的程式(OpenCV就有)納入我的軟體，確實可以直接讀取串流資料自行解碼之後做辨識，但是因為解碼運算必須使用CPU，佔去太多原本可用於辨識的運算資源，辨識速度就會只剩下3-5Hz了！

這些實驗在四五年前我都做過了！如果我堅持將解碼功能納入我的軟體，辨識頻率低到個位數，我的動態辨識產品優勢就完全消失了！所以我不這麼作，是不為也，非不能也！自行解碼唯一的好處只有一個，就是「不佔螢幕」空間，因為我必須拷貝螢幕現狀做辨識，如果顯示中的影片或攝影機畫面被其他工作視窗遮蔽，或被收納到工作列就辨識不到了！

但螢幕使用的衝突是極好解決的小問題，用雙螢幕就好了！主螢幕你可以繼續做任何事情，副螢幕專責顯示串流影像供我的軟體拷貝辨識即可，要省電嗎？設定好辨識區域啟動辨識之後，你將螢幕電源關掉都還是可以繼續辨識的！因為我們拷貝的影像其實是來自記憶體的特定區域，跟實體螢幕是否存在或是否實際運作(顯示畫面)中都是無關的！

這個程序架構其實是最有效運用電腦做快速動態影像辨識的方式，也有人老是問我我的辨識有沒有用到GPU？其實GPU就是顯示卡內的CPU，所以我也可以回答說我是有用到GPU的！但不是用來分散辨識程序的運算，而是利用它們解串流資料的高效率。

我的辨識程序本身非常有效率，不像CNN那麼低能需要太大量的運算，當然就不需要GPU幫我做辨識了！對我的辨識流程概念來說GPU是個太過簡化的運算單元，好像幼稚園的小孩在廚房中幫不上甚麼忙一樣！但是CNN架構的底層有太多全面性的暴力運算，計算量太大，如果不用GPU就會太慢了！CNN需要大量童工，我不需要！

這樣做無形的好處就是：不管任何廠牌型式的攝影機，不管任何格式的串流壓縮檔案，我都可以辨識！只要電腦作業系統與顯示卡可以讀懂顯示在螢幕上的影像我都可以辨識！試問我的軟體有可能比作業系統認識更多串流影像格式嗎？有可能比作業系統更能處理各種播放串流時發生的例外狀況嗎？我必須讓我的軟體變得跟作業系統一樣功能完整繁雜龐大嗎？

看完以上的說明，各位就應該可以理解，我不直接接串流來源做辨識軟體，才是最契合現有的電腦環境，最聰明合理的選擇！就像我明明有一輛很好的汽車，有事出門時當然開車最方便，不要老是問我為何不走路或坐公車了！這是整體效益考量的最佳化設計，跟我的技術好不好？會不會寫「解串流」的程式無關的！

至於動態辨識的軟體車行方向能否辨識？答案很明顯，一定可以！因為我內部有大量的單張影像原始辨識資料，每個影像辨識到車牌後也一定知道它在畫面中的位置座標，我當然也可以記錄該影像取得的時間，這樣我就有某車牌移動的軌跡了！剛剛在哪裡？現在到哪裡？我都知道的！要我告訴你車行方向當然沒問題，看下面的視訊就知道了！