大家好！
雲端視訊監控服務最近越來越受歡迎可能已經不是什麼秘密了。 發生這種情況的原因很明顯，影片是「重」內容，其儲存需要基礎設施和大量磁碟儲存。 使用本地視訊監控系統需要資金來運作和支持，無論是對於使用數百個監視攝影機的組織還是對於擁有多個攝影機的個人用戶。
雲端視訊監控系統透過為客戶提供現有的視訊儲存和處理基礎設施來解決這個問題。 雲端視訊監控客戶端只需將攝影機連接到網路並將其連結到他的雲端帳戶即可。
有多種技術方法可以將攝影機連接到雲端。 毫無疑問，最方便、最便宜的方法是攝影機直接與雲端連接並工作，無需伺服器或錄影機等額外設備的參與。
為此，需要在相機上安裝與雲端配合使用的軟體模組。 然而，如果我們談論廉價相機，那麼它們的硬體資源非常有限，幾乎100%被相機廠商的原生韌體佔用，並且沒有雲端插件所需的資源。 ivideon的開發者專門解決了這個問題 ，這解釋了為什麼他們不能在廉價相機上安裝該插件。 因此，相機的最低價格為 5000 盧布（80 美元），並且在設備上花費了數百萬美元。
我們已經成功解決了這個問題。 如果您對如何進行感興趣 - 歡迎來到剪輯
歷史上的位
2016年，我們開始為Rostelecom開發雲端視訊監控平台。
在相機軟體方面，在第一階段，我們遵循「標準」路徑來完成此類任務：我們開發了自己的插件，該插件安裝在供應商相機的標準韌體中並與我們的雲端配合使用。 但值得注意的是，在設計過程中我們使用了最輕量級、最高效的解決方案（例如，protobuf、libev、mbedtls 的純 C 實作以及完全放棄像 boost 這樣方便但笨重的函式庫）
目前，IP攝影機市場上還沒有通用的整合解決方案：每個供應商都有自己的插件安裝方式、自己的一套用於操作韌體的API以及獨特的更新機制。
這意味著對於每個相機供應商來說，有必要單獨開發一個全面的整合軟體層。 在開始開發時，建議僅與 1 個供應商合作，以便團隊專注於開發與雲端配合使用的邏輯。
第一個選擇的供應商是海康威視，它是攝影機市場的全球領導者之一，提供了詳細記錄的 API 和強大的工程技術支援。
我們使用海康威視攝影機啟動了第一個試點計畫「雲端視訊監控 Video Comfort」。
發布後幾乎立即，我們的用戶就開始詢問是否可以將其他製造商的更便宜的相機連接到該服務。
我幾乎立即拒絕了為每個供應商實施整合層的選擇 - 因為它的可擴展性很差並且對相機硬體提出了嚴格的技術要求。 滿足這些輸入要求的相機成本：~60-70 美元
因此，我決定深入挖掘 - 為任何供應商的相機製作自己的韌體。 這種方法顯著降低了對相機硬體資源的要求 - 因為用於使用雲端的層與視訊應用程式的整合更加有效，並且韌體中沒有不必要的未使用的脂肪。
重要的是，在低階使用相機時，可以使用硬體 AES，它可以加密數據，而不會對低功耗 CPU 造成額外負載。
那一刻我們什麼都沒有了。 什麼都沒有。
幾乎所有供應商都沒有準備好在如此低的水平上與我們合作。 沒有有關電路和組件的信息，沒有晶片組和感測器文件的官方 SDK。
也沒有技術支援。
所有問題都必須透過逆向工程——反覆試驗——來回答。 但我們做到了。
我們測試的第一批相機型號是小米易蟻、海康威視、大華、Spezvision、D-Link相機和幾款超便宜的無名中國相機。
技術
基於海思3518E晶片組的相機。 相機的硬體特性如下：
小米蟻蟻
NONAME
系統芯片
海思3518E
海思3518E
內存
64MB
64MB
閃光
16MB
8MB
無線網絡
mt7601/bcm43143
-
傳感器
ov9732 (720p)
ov9712 (720p)
乙太網路 - ENET
-
+
的MicroSD
+
+
麥克風
+
+
揚聲器
+
+
愛爾蘭人
+
+
紅外線切割
+
+
我們從他們開始。
我們目前支援海思 3516/3518 晶片組以及 Ambarella S2L/S2LM。 有數十種相機型號。
韌體組成
uboot
uboot是引導程序，它在上電後首先啟動，初始化硬體並載入linux核心。
相機載入腳本非常簡單：
bootargs=mem=38M console=ttyAMA0,115200 rootfstype=ramfs mtdparts=hi_sfc:256K(boot),64K(tech),4096K(kernel),8192K(app),-(config) hw_type=101
bootcmd=sf probe 0; sf read 0x82000000 0x50000 0x400000; bootm 0x82000000; setenv bootargs $(bootargs) bkp=1; sf read 0x82000000 0x450000 0x400000; bootm 0x82000000特點之一是被呼叫兩次 bootm，稍後當我們談到更新子系統時，會詳細介紹這一點。
注意線路 mem=38M。 是的，是的，這不是拼字錯誤 - Linux 核心和所有所有應用程式只能存取 38 MB 的 RAM。
在 uboot 旁邊還有一個特別的區塊，稱為 reg_info，其中包含用於初始化DDR和SoC的一些系統暫存器的低階腳本。 內容 reg_info 取決於相機型號，如果不正確，相機甚至無法加載uboot，而且會在加載初期卡住。
起初，當我們在沒有供應商支援的情況下工作時，我們只是從原始相機韌體中複製了這個塊。
Linux 核心和 rootfs
相機使用 Linux 內核，它是晶片 SDK 的一部分；通常這些不是 3.x 分支的最新內核，因此我們經常不得不處理附加設備的驅動程式與所使用的內核不相容的情況，我們必須將它們向後移植到內核相機。
另一個問題是內核的大小。 當 FLASH 大小只有 8MB 時，每個位元組都很重要，我們的任務是仔細停用所有未使用的核心函數，以將大小減小到最小。
Rootfs 是一個基本的檔案系統。 這包括 busybox、wifi模組驅動、一套標準系統庫，如 libld и libc，以及我們的軟體，負責 LED 控制邏輯、網路連接管理和韌體更新。
根檔案系統作為 initramfs 連接到內核，建構的結果是我們得到一個文件 uImage，其中包含內核和 rootfs。
視訊應用
韌體中最複雜且資源密集的部分是應用程序，它提供視頻音頻捕獲、視頻編碼、配置圖像參數、實現視頻分析（例如運動或聲音檢測器）、控制 PTZ 並負責切換日和日。夜間模式。
一個重要的，我甚至可以說是關鍵的功能是視訊應用程式如何與雲端插件互動。
在無法在廉價硬體上工作的傳統解決方案「供應商韌體+雲端插件」中，攝影機內的視訊透過RTSP協議傳輸——這是一個巨大的開銷：透過套接字複製和傳輸數據，不必要的系統調用。
在這裡，我們使用共享記憶體機制 - 視訊不會透過相機軟體組件之間的套接字複製或發送，從而最佳且謹慎地使用相機的適度硬體功能。
更新子系統
特別值得驕傲的是用於線上韌體更新的容錯子系統。
讓我解釋一下這個問題。 更新韌體從技術上來說並不是原子操作，如果更新過程中發生斷電，那麼快閃記憶體中將包含部分「未寫入」的新韌體。 如果不採取特殊措施，相機就會變成一塊“磚頭”，需要送到服務中心。
我們也處理過這個問題。 即使相機在更新過程中關閉，它也會自動從雲端下載韌體並恢復操作，無需用戶幹預。
讓我們更詳細地看看該技術：
最容易受到攻擊的點是用 Linux 核心和根檔案系統覆蓋分割區。 如果這些組件之一損壞，相機將無法在 uboot 引導程式之外啟動，而 uboot 引導程式無法從雲端下載韌體。
這意味著我們需要確保相機在更新過程中隨時都有可用的核心和rootfs。 看起來最簡單的解決方案是在快閃記憶體上不斷儲存帶有 rootfs 的核心的兩個副本，如果主核心損壞，則從備份副本載入它。
一個很好的解決方案 - 然而，帶有 rootfs 的核心佔用大約 3.5MB，並且對於永久備份，您需要分配 3.5MB。 最便宜的相機根本沒有那麼多可用空間用於備份核心。
因此，為了在韌體更新期間備份內核，我們使用應用程式分區。
並使用兩個命令來選擇內核所需的分區 bootm 在 uboot 中 - 一開始我們嘗試載入主內核，如果它損壞，則載入備份內核。
這確保了在任何給定時間相機都將具有帶有 rootfs 的正確內核，並且能夠啟動和恢復韌體。
用於建置和部署韌體的 CI/CD 系統
為了建立韌體，我們使用gitlab CI，它會自動為所有支援的相機型號建立固件，建立韌體後，會自動部署到相機軟體更新服務。
透過此服務，韌體更新將傳送到我們的 QA 測試相機，並在完成所有測試階段後傳送到使用者的相機。
信息安全
眾所周知，當今資訊安全是任何物聯網設備（包括相機）最重要的方面。 像 Mirai 這樣的殭屍網路正在網路上漫遊，利用供應商的標準韌體感染數百萬台相機。 出於對相機供應商的應有尊重，我不得不指出，標準韌體包含許多與雲端一起使用不需要的功能，但包含殭屍網路利用的許多漏洞。
因此，我們的韌體中所有未使用的功能都已停用，所有 tcp/udp 連接埠都已關閉，並且在更新韌體時，會檢查軟體的數位簽章。
除此之外，韌體還會在資安實驗室進行定期測試。
結論
現在我們的韌體積極用於視訊監控項目。 其中最大的也許是俄羅斯聯邦總統選舉當天的投票廣播。
該專案涉及 70 萬多台裝有我們韌體的攝影機，這些攝影機安裝在我國的投票站。
在解決了許多複雜的、在某些地方甚至在當時幾乎不可能的問題之後，我們作為工程師當然得到了極大的滿足，但除此之外，我們還節省了數百萬美元購買相機的費用。 在這種情況下，節省的不僅僅是文字和理論計算，而是已經完成的設備採購招標的結果。 因此，如果我們談論雲端視訊監控：有兩種方法：策略上依賴低水平的專業知識和開發，從而節省大量設備，或者使用昂貴的設備，如果你專門考慮消費者特徵，這實際上是沒有的與同類便宜貨不同。
為什麼儘早決定集成方法的選擇具有戰略重要性？ 開發外掛時，開發人員依賴某些技術（函式庫、協定、標準）。 如果只為昂貴的設備選擇一套技術，那麼將來嘗試改用廉價相機很可能至少會花費非常長的時間甚至失敗，然後就會回歸昂貴的設備。
來源： www.habr.com