一、背景

隨著智能家居與物聯網的普及，網絡攝像頭（IPC）逐步滲透到家庭、幼兒園、小店商鋪等場景；國家推進的天網工程、雪亮工程讓公共場所都安裝上了監控攝像頭；數字化與智能化的趨勢也讓園區、學校、工廠遍布視頻攝像頭。除了典型的安防監控攝像頭，還有越來越多的視頻類IOT新產品涌向市場（例如可視門鈴、行車記錄儀、可視門禁等）。5G時代到來后，視頻在物聯網場景下的應用也會越來越豐富。

1. 家用攝像頭的聯網功能是剛需

十多年前，攝像頭還是主要用在安防監控領域。主要應用的場合一般是公共場所或對安全要求較高的地方。隨著智能家居的普及，家用攝像頭進入大眾的視野。家用攝像頭解決的用戶需求主要是看家、看老人、看小孩、看寵物。而這都需要能讓用戶在任何時間、任何地點，通過互聯網就能方便的訪問到家里攝像頭設備。

2. 視頻監控“聯網”是實現數字化和智能化的前提

隨著產業互聯網的發展, 越來越多的傳統企業在做數字化、智能化轉型。視頻監控是其中一個核心的要素，因為視頻能直觀的記錄完整場景、保留所有的信息，是單純的傳感器所不可比擬的。即使因為當前的技術限制、業務關注點等原因沒有提取所有的相關信息，只要保存原始的監控視頻數據，在未來還是可以完成追溯和提取分析的功能。傳統的視頻監控大多是基于局域網或專用網絡的，必須進行改造。

3. 云服務能力是硬件廠商的痛點

對于攝像頭、NVR等與視頻相關的硬件廠商而言，競爭的點不再局限于硬件的品質、功能、成本，云能力成為一個至關重要的一個環節。硬件廠商感受到行業趨勢的變化，積極的去擁抱新的變化，但是也碰到一些困難。

• 1）技術和財力上無法支撐技術密集、重資產的視頻云服務

視頻技術涉及網絡傳輸、視頻編解碼、圖像音頻信號處理、媒體協議與容器、視頻播放與控制等諸多技術，是一個技術密集型的領域。視頻領域的專業人才比較稀缺，而把視頻技術應用在嵌入式和物聯網設備領域，更加提升了對技術人員的挑戰。而且硬件廠商的技術人員的技術棧多在硬件和終端技術上，在云服務上幾乎無任何積累。

另外，云計算服務一般都是重資產。一方面為了解決全網的網絡覆蓋問題，讓每個用戶都能有非常好的體驗，就需要在全球部署很多IDC節點。另一方面，視頻數據的數據量非常大，對云服務的規模要求非常高。硬件廠商大部分都是中小規模的公司，根本不具備自己建設大規模視頻云服務的能力。

• 2）硬件的利潤變薄，需要增值服務帶來新的利潤空間

對于硬件廠商而言，屬于傳統制造業，主要的利潤來源是硬件的一次性售賣。隨著競爭的日益加劇，硬件廠商毛利空間越來越小，硬件廠商也迫切需要尋找新的獲利方式。隨著云計算的發展與智能化的趨勢，給了硬件廠商新的機遇。相比一次性的硬件售賣，提供增值云服務可以獲得更持久、更穩定的收入來源。

4. 視頻對傳統物聯網云帶來的挑戰

傳統的物聯網云，解決了設備接入、設備管理、數據采集、OTA 升級等基礎功能。通信的數據量一般來說相對較小，不會對物聯網云帶來較大的影響。但對于視頻類的設備，視頻的數據量巨大，傳統的物聯網云的數據通道無法承載海量的視頻類數據。泛娛樂場景，已經有通用的 CDN 和存儲基礎設施來支持，但是物聯網的視頻有其特殊的場景需求，需要有專用的系統和平臺解決這一垂直領域的各類問題。360 物聯網視頻服務（
https://zyun.360.cn/product/iot）就是為了解決這個場景下的問題，從而成為物聯網領域視頻的底層基礎設施。

二、帝視：360智匯云物聯網場景下的視頻解決方案

1. 帝視提供的基礎能力

對于視頻類物聯網設備，常見的需求有以下的幾類，帝視 SDK 能覆蓋下列所有的視頻需求

• 1）隨時隨地的遠程觀看實時直播與 PTZ 控制

無論是家用攝像頭還是監控類攝像頭，用戶都有遠程隨時隨地查看當前實時視頻的需求。用戶的移動設備的網絡可能與設備所在的網絡不在同一個運營商，甚至都不一定在同一個地域。如何讓用戶快速、流暢的觀看實時視頻就成了核心要解決的問題。除了能看到畫面，對于支持云臺的攝像頭，還需要可以通過遠程的操控控制攝像頭的轉動和對焦，方便用戶實時的捕捉和跟蹤動態的目標物體。

• 2）卡錄存儲與遠程錄像查看

一般的攝像機都可以帶本地的存儲卡，能存儲一段時間的完整錄像。通常在發生了特定的事情或需要追溯時，用戶需要遠程查看存儲在攝像頭存儲卡上的錄像內容。由于錄像的時間比較長，需要能方便準確的定位到對應的時間段。還要提供快進、后退、倍速、跳幀播放等高級的功能提升追溯的效率。對于NVR的場景，卡錄則對應NVR上的本地存儲。

• 3）遠程語音對講或視頻通話（RTC）

視頻類攝像機除了能采集視頻外，一般還帶有麥克風和揚聲器。這樣就使得遠程的用戶可以和設備端的用戶進行實時的互動。通常有半雙工和全雙工兩種方式。如果設備自身帶顯示屏幕，還可以進行雙向的視頻通話。RTC功能提供低延遲的傳輸與3A算法（回聲消除、降噪、自動增益控制），對于一些配置比較低的設備需要硬件或廠商提供3A算法的軟硬件實現支持。

• 4）遠程訪問設備上的文件

對于 NVR 設備和NAS 設備，設備側存在很多以文件方式存儲的內容(如事件視頻、相冊內容)，遠程的用戶也需要通過簡單的方式訪問到這些內容，而不需要把這些內容上傳到云端。

• 5）云存上傳與管理

除了設備上的存儲卡，還可以把視頻錄像上傳的云存儲上，解決設備損壞、暴力拆除的問題，在一些緊急事情的場景，也能記錄最后最重要的關鍵畫面(設備可能被犯罪分子先破壞)。視頻監控內容上傳到云端存儲后，還可以開通更多的增值服務，進行 AI 分析，使得安防事件報警更加精準。

• 6）行業標準支持

由于硬件廠商眾多，為了讓各家的產品的視頻數據能互聯互通，目前行業內形成了多個標準。帝視提供對應的SDK來支持第三方的標準。目前主流的GB28181、ONVIF、RTMP、RTSP協議都支持。

• 7）其他增值服務

• AI增值服務： 人臉檢測、人臉識別；人形檢測；哭聲檢測；
• 傳統算法：畸變矯正、移動偵測、聲波配網算法

2. 帝視的組成框架圖

帝視服務是一個PaaS服務，提供全平臺的終端SDK和云端服務。客戶需要有開發能力，把帝視的SDK集成到自己的應用里。帝視封裝了幾乎所有與音視頻相關的部分，使得客戶不需要關心底層復雜的音視頻的存儲、傳輸、播放，就能享受到帝視服務的極致視頻體驗。

3. 典型應用場景

帝視可以應用到所有帶音視頻采集的嵌入式設備上。除了常見的IPC攝像頭外，像聯網版本的行車記錄儀、可視門鈴、可視門鎖、可穿戴設備（兒童手表、老人手表）等等都可以使用帝視的視頻能力，讓用戶跨越時間和空間的限制，隨時隨地的以音視頻的方式與設備進行溝通。近幾年，低功耗品類的嵌入式設備也逐步流行，帝視也能支持多種低功耗方案。

帝視還可以應用于NVR設備上，使得傳統的攝像頭接入NVR后，也可以在公網上被安全的訪問，特別適合利舊的場景。

三、帝視服務的關鍵技術

1. 強大的私有傳輸協議和分發網絡

• 1）P2P 技術節省90%+的服務器帶寬

不管是實時視頻查看，還是存儲卡錄像的查看，數據都需要從設備端流向遠程移動 App 上。如果所有的流量都走服務器的中轉，那么這個帶寬成本會非常巨大。360 視頻云通過 P2P 技術，讓移動終端用戶和智能硬件設備間，通過點對點的鏈路進行通信，并利用 360 自研的私有傳輸協議做擁塞控制，即節省了服務器中轉的帶寬，同時保持了良好的傳輸效率，弱網下也能有良好的表現。正常情況下，90%以上的帶寬可以走P2P 的方式，從而極大的節省了成本。另外，利用P2P技術，也可以實現用戶到設備局域網的隧道(Tunnel)，可以讓用戶遠程訪問設備局域網內的其他網絡服務。

• 2）弱網表現強勁的私有傳輸協議

帝視的私有傳輸算法在丟包率到達30%時，還能比較充分的利用帶寬。而傳統的TCP則對丟包特別敏感，隨著丟包率的上升，吞吐量急劇下降。基于BBR算法的TCP或QUIC則相對表現好些，但是在超高丟包率的場景下表現也略差。（如下表）

表格：帝視私有傳輸協議與公開協議在弱網下的效果對比（條件： 5Mbps帶寬，50ms延時）

• 3）全球覆蓋的Relay中繼網絡

在國內市場趨向飽和的情形下，越來越多的硬件廠商把目光轉向了海外的市場。為了實現海外的覆蓋，帝視的Relay中繼以及P2P服務都進行了全球部署。未來根據業務需要，也會拓展覆蓋的地區和規模。

• 4）支持傳遞智能幀信息

未來越來越多的終端設備會攜帶AI算力，在數據采集到第一時間，就可以進行AI分析。對于AI提取到的檢測結果（比如人臉識別信息），也需要有通道進行傳遞。通常AI檢測的結果信息需要在視頻播放時同步展示出來，比如需要在播放畫面上用矩形框出檢測到的人臉，并顯示一些人臉屬性信息。如果AI檢測結果的信息與視頻流是分開傳輸與存儲的，就很難在播放時同步的展示檢測結果信息。

帝視的SDK提供一個存儲視頻幀Meta信息的機制，可以為每一幀都存儲一段任意大小的二進制數據，它和視頻流信息是一起傳輸和存儲的。在用帝視的播放器進行播放時，會把即將渲染的視頻幀攜帶的Meta信息回調給業務層，供業務層自己解析出來進行疊加展示。

2. 支持多種低功耗方案

物聯網設備的普及，除了基礎的通信功能外，還受限與一些物理場景，比如供電、物理尺寸等。很多的應用場景無法保證長時間的物理供電，比如室外的一些設備、移動的設備等。一方面要保證整體功耗極低，使用電池就能滿足較長的待機時間(通常幾個月或一年以上)，另一方面又要保證無間斷的工作，不能因為節省電量導致遺漏處理事件。

對于傳統的一些物聯網設備，可以通過改進無線通信方式、操作系統、采用低功耗芯片來解決低功耗問題。物聯網場景下的無線通信方式通常有藍牙、Zigbee、NBIot、zWave以及 WiFi 等多種方式。不同的無線通信方式有著不同的通信距離、通信速率和功率消耗。但對于視頻類應用而言，需要的帶寬和傳輸的數據量非常大，使得 Zigbee、zWave以及 NBIot 這些方式不能滿足需求，而藍牙也需要添加額外的網關才能接入互聯網。

在系統和芯片選擇上，有通用的操作系統(比如 Linux)和特定場合下使用的系統可供選擇。通常來說通用的系統功能擴充方便，軟件移植和維護也都比較簡單，但對應的開銷也會比較大。專用的系統(比如 RTOS)則簡化了通用系統的很多功能，只保留了最少且必要的部件，使得滿足業務功能的同時，極大的降低的開銷，但在軟件移植和代碼維護方面都有較大的難度。

帝視提供了單系統和多系統兩種低功耗方案的支持

• 1）單系統方案

單系統方案一般采用RTOS或LiteOS系統方式，模塊功能根據需要進行裁剪和移植。單用單系統的方式一般也會只在需要的時候才去加載特定的功能模塊，盡量減少不必要的開銷。同時對于保活、喚醒觸發機器都需要做專門的優化。

• 2）雙系統方案

雙系統方案結合了通用操作系統和專用的系統兩者的優點，如下圖所示：

系統由兩個部分組成，一部分是常駐的 RTOS 系統，維持很低功耗運行，同時監測傳感器和遠程的網絡觸發喚醒請求。當滿足觸發條件，比如有人經過智能可視門鈴，或者用戶通過 App 遠程喚醒時，RTOS 系統再喚醒Linux 系統。Linux系統再來完成正常的業務功能。這種方案兼顧通用系統和專有系統的優點，既保證了軟件移植和開發維護的效率，同時也達到低功耗的目標。

3. 多級存儲技術

不管是傳統視頻監控領域還是逐步普及的家用網絡攝像頭，視頻內容的錄像存儲都是一個比較有挑戰的課題。傳統的監控錄像分為攝像機終端上的卡錄、NVR上的存儲兩種場景。隨著數字化和智能化的發展需要，越來越多的場景會把視頻流實時的上傳到云端進行存儲。視頻監控內容因為其數據量大、特殊的訪問模式等因素，需要有針對性的進行設計。視頻監控的存儲系統是一個專門為垂直場景而設計的，根據視頻數據的特性、存儲介質的特性、訪問模式等，針對場景做了很多Tradeoff，從而獲得想要的表現。

在訪問模式上，視頻監控的錄像存儲只需要記錄一次，而在使用的時候則可能被多次反復的讀取。訪問的pattern通常是從某個時間點按順序提取數據，提取的粒度通常是某個視頻通道，持續的時長則根據實際的場景情況有較大差異。如果讀取是用播放器來播放，播放器還支持倍速、前進、回退、跳幀播放等。總體概括起來就是：小范圍連續，大范圍跳躍，按時間檢索。

• 1）設備端卡錄

設備端的卡錄是把錄像數據存儲到設備本地的存儲卡上，當存儲滿后進行循環淘汰覆蓋。始終保持最新的錄像數據。例如一個16GB的卡，如果碼率是512kbps，7x24小時錄像，大約可以存儲3天的時長。不管是FAT32還是ext3/ext4文件系統，都可以分為meta信息部分和真實的數據區部分。在讀寫非常頻繁、設備掉電等多種情況下，會導致meta信息與數據的不一致。在普通pc和服務器上可以有一些fsck之類的工具進行修復。但對于嵌入式系統，我們需要盡量避免這種情況的出現。

對于存儲設備，通常是按Sector/Block來管理的，一個邏輯文件通常包含很多個扇區，隨著文件的創建、刪除、修改，會讓整個磁盤的扇區使用情況形成諸多碎片。碎片一方面會導致讀取時帶來隨機訪問降低吞吐，另外一方面在寫入時也需要花費更多的時間來分配合適的扇區寫入新的數據。另外，對于Flash存儲設備，頻繁或非法的讀寫還會導致進入寫保護狀態，無法繼續寫入錄像數據。

基于上述的原因，帝視的本地卡錄存儲采用的方式是固定塊循環覆蓋寫的方式。初次創建的時候，可以不預先占用空間，等逐步寫入視頻數據后逐步增加大小，一旦寫滿后，文件就不再刪除，通過循環覆蓋的方式淘汰舊的歷史數據。

全時段錄像 vs. 事件觸發型

由于全時段錄像需要大量的存儲空間，帶來比較高的成本。而實際情況下，視頻畫面在很多場景下并沒有任何有用的信息，比如一個無人的室內場景，畫面絕大部分時間都是靜止的，但是錄像還是一直在存儲，浪費存儲空間。雖然視頻編碼的VBR技術可以在畫面靜止是降低大部分的碼率，為了保證一定的清晰度，最小的碼率還是很高。一個可行的辦法就是當畫面的內容有變化或者有感興趣的事件發生時，才對視頻流進行錄像存儲。典型的方式是加上移動偵測算法或人臉、人體檢測算法，當有事件觸發時，錄像立即開啟。這種方式即不會漏掉事件，也不會浪費存儲空間。

磁盤空間管理

由于存儲設備的容量是有限的，隨著時間的推移，錄像數據一定會裝滿整個存儲區域。當存儲空間耗盡后，需要有一定的方式對老的存儲空間進行重復利用。另外，除了視頻錄像，還有一些額外的信息也需要存儲，比如截圖，業務數據和日志之類的。帝視服務的磁盤管理支持多樣的模式來管理磁盤空間。

• 最大使用空間：存儲錄像的部分不會超過這個限制容量
• 最小保留空間：始終要保留一個固定容量的空間，比如512MB
• 最小保留比例：始終要保持超過10%的剩余空間

• 2）NVR本地存儲文件系統

NVR 設備通常有許多個通道，每個通道會對應一路攝像頭。每個通道的視頻流會以某種格式存放在本地的磁盤上。通常來說，由于要保存較長時間的視頻錄像，需要較大的磁盤容量。目前市面主流的磁盤有機械盤、固態盤以及混合兩種特性的混合盤。機械盤因為其容量大、價格低而成為 NVR 存儲磁盤的首選。

機械磁盤的一個顯著特性就是存在尋道時間，導致隨機訪問和順序訪問有這極大的性能差異。機械盤順序讀寫的吞吐是優于隨機讀寫的。雖然對于單路視頻流錄像而言，是滿足順序寫入的，但是如果很多路(比如 16 路、32 路)同時寫入還是會讓磁頭反復尋道。磁盤本身的 NCQ 技術雖然能緩解一部分，但是無法從根本上解決。

另外，NVR系統是一個 7x24 小時不間斷的存儲系統，隨著時間的推移，最終會耗盡所有的磁盤存儲空間。典型的策略采用覆蓋淘汰掉最老的錄像數據的方式，從而保持始終留存這個最新的錄像數據。

磁盤一般會有 OS 提供的文件系統，錄像數據則以一定的組織方式存在磁盤上，如果數據的組織方式不恰當，數據持續的淘汰會帶來磁盤碎片，帶來更多的尋道操作而影響性能，隨著時間的推移，這個現象會越來越嚴重。

帝視 SDK 的存儲系統是經過專門設計的數據組織方式，一方面保證很多路視頻流寫入時沒有隨機寫入問題，另一方也保證數據的覆蓋淘汰不會帶來碎片問題影響性能。另外，在掉電后只有最后寫入的數據幀會受影響，其他的數據都不會收影響，確保數據的安全性。在NVR的場景，通常會掛載多塊硬盤。為了提升整體的吞吐，需要把碼流的寫入分攤到多塊磁盤上，并行寫入。另外為了保證數據的安全性，也可以使用多個磁盤來做RAID。

• 3）云端存儲與云存服務

卡錄和NVR存儲有著成本低廉的優勢，但是無法應對盜搶和損壞問題。犯罪分子發現有攝像頭時一般就會第一時間去破壞攝像頭，導致無法通過監控錄像來提供線索抓捕犯罪分子。普通的存儲卡在多次插拔和一定時間的寫入后，特別容易損壞。云端存儲的方式則不受這些影響。另外，數據存儲到云端，還可以進行有效的分析和處理，提取出更有效的信息，提升追溯問題時的效率。比如視頻通過結構化分析處理后，就可以很方便的去搜索人、車和物品信息，并能快速、準確的定位到具體的時間和地點。同時，這些數據還能同其他業務數據形成數據湖，實現協同的價值。

把攝像頭的實時視頻數據上傳到云端，有多種實現方式，對應帝視SDK的多種云存模式

流式傳輸 vs. 切片文件

攝像頭的視頻流本身是流式的，但是一般的云存儲都是對象存儲，并不是一個無始無終的流式文件，必須要把流式的視頻流切割成一個個的文件。通常可以把流式的文件切割后存儲成特定的容器格式，比如MP4和TS。因為MP4文件的寫入通常涉及到索引的處理，需要seek到文件頭進行索引位置的更新操作，并不適合邊傳輸邊寫入。TS則比較方便，無需索引位置的更新，不過TS文件的overhead相對mp4來說要高一些。

設備端直接上傳 vs. 云端切片上傳

雖然最終都需要對視頻流進行切片，但是切片在設備上完成還是在服務器上完成，還是可以選擇的。IPC設備上直接切片上傳的好處是無需服務端處理，IPC設備側完成所有的邏輯，缺點則是需要本地緩存一定量的數據，在切片沒有緩存完成前，無法進行上傳操作。如果切片在云端進行，那么就需要把碼流推送到云端的服務器主機上（或者服務端主動去拉流），由這個服務器主機來對視頻流進行切片和上傳的云存儲里。云端切片的方式能節省IPC設備端的緩存開銷，IPC只需把流數據發送出來，就不用做任何其他事情了。

云端Meta信息存儲

視頻錄像的切片存儲到云存儲后，還需要對meta信息進行管理。由于這些數據是一系列的時間序列，可以用時序數據庫進行存儲。對于直接播放的場景，服務端可以根據請求的時間段動態拼成m3u8文件返回給終端進行播放。如果需要導出，也可以轉封裝。

帝視服務提供云存的切片和上傳功能，支持主流的對象存儲服務(AWS 的 S3、阿里云的 OSS、智匯云的S3存儲)。由于第三方存儲服務都是上行免費的模式，帝視SDK 可以直接從設備端上傳視頻數據到云存服務。同時在弱網的時候，利用本地卡錄來做緩存，不會因為短暫的網絡中斷而丟失云存數據。

4. 完善的視頻能力

• 1）靈活的播放能力

對于基于攝像頭類的應用場景，視頻內容的實時觀看與錄像回溯是最基礎的功能。但是對于物聯網場景，比如安防監控的視頻播放、家用攝像頭的視頻播放與傳統場景不太一樣的地方就是能在公網上遠程觀看視頻，并且利用P2P技術節省大量流量帶寬。

實時監控播放

對于實時監控的視頻播放與直播的模式類似，但不限于使用標準的直播協議。帝視的實時監控視頻播放時建立在私有傳輸協議之上，即可能是P2P的鏈接，也可能是通過Relay服務器中轉。一旦通信的信道建立之后，就可以以流式的方式傳輸采集編碼后的音視頻數據幀。播放的途中可能會伴隨底層鏈路的切換。

為了保障好的開流體驗，在IPC設備上通常會緩存最新的一個GOP數據，遠程請求播放時會第一時間從頭發送這個GOP數據。播放端拿到首幀數據其實就可以渲染出來。緩存GOP會降低開流的首屏時間，但是因為緩存了部分數據，會帶來一定的延遲。當GOP較大時這個現象更明顯。解決的方式就是播放器可以做一些追幀、丟棄等策略，盡快消費掉緩沖的多余數據，始終在消費最新的數據。播放器可以提供流暢和低延遲兩種播放模式供用戶選擇。流暢模式緩存的數據會多一些，能對抗更大的網絡間歇或抖動，但延遲相對較高。而低延遲模式緩存極少量的數據，使得延遲相對較低，但是也更容易出現卡頓。

錄像視頻播放

偽直播模式 vs. 純點播模式：對于傳統的短視頻和長視頻內容，通常采用HTTP協議下載播放的模式。通過HTTP1.1版本支持的Range請求頭來處理seek到指定時間點播放的問題。監控視頻的存儲則有些不同，為了解決磁盤碎片帶來吞吐量降低問題，監控系統采用的存儲是固定占位、循環覆蓋寫的方式，本地文件系統上并不是標準的MP4或其他標準格式的文件。另外，對于監控視頻的回看播放而言，一般是有目的的進行目標搜索，所以會進行頻繁快進、倍速和慢速、定格、跳幀播放，會有頻繁交互式播控操作。

比較容易想到的一種方式是HTTP Over P2P Connection，這種方式一方面需要在P2P連接上實現完整的HTTP協議棧，另外一方面還要求IPC上存儲的文件是標準的媒體文件格式。HTTP方式下載文件對于下載數據量的也不好控制，可能下載了很多數據并不會被觀看，造成帶寬流量的浪費。這幾個方面都不太適合錄像監控的模式。

第二種方式是通過使用像RTSP之類的帶播控操作的協議，即可以指定播放的起止時間，播放的數據也是以“偽直播”的模式，按播放的速率推送的數據，不會造成數據的浪費。這種方式非常適合在局域網或者專網環境。對于目標場景是遠程跨公網訪問，并且大部分的流量都會走P2P的連接，要實現一套RTSP Over P2P Connection也會有復雜的開銷。

除此之外，遠程錄像的查看方，還需要展示錄像的時間段（顯示成時間軸，有錄像的地方一種顏色，無錄像的地方是空白或灰色標識），這個時間軸信息的請求和交互也需要進行通信和交換。

綜合考慮下來，聯網式的監控場景采用的是基于私有協議的播放控制，直接在P2P連接上實現一套偽直播協議，支持快進、后退、倍速、跳幀播放，也支持時間軸信息的獲取與更新。除了常規的視頻播放能力，帝視的播放器還支持對局部畫面進行縮放與平移。

網絡與播放的解耦

由于是用私有傳輸協議來傳輸數據，通用的標準播放器肯定是無法直接來播放監控視頻流。監控場景下，一般提供自研的播放器來解決這個問題。標準的播放器會為每一種協議提供一個Demuxer來做媒體協議的解封裝，對于私有協議，也可以使用類似的方式。但在監控領域，通常采取的是另外一種方式，通過API接口的方式，把音視頻幀數據以內存的方式傳遞給播放器，播放器再去做解碼、同步和渲染操作。這種方式有一個很大的優點：網絡和播放解耦。廠商提供一個通用的NetSDK，處理所有數據傳輸和信令問題，和播放器配合起來就可以完成復雜的播放和控制。

Web端無插件播放H265監控視頻

傳統的視頻監控的視頻墻通常是專門的桌面程序（比如基于QT編寫的桌面程序），或者是瀏覽器安裝ActiveX插件或其他Plugin的方式，實現私有協議的播放。同時，由于是Native實現的播放代碼，在播放性能和體驗上也能做得比較好。

帝視則支持Web端無插件的播放監控視頻（通過FLV或WebSocket來獲取視頻流)。對于傳統直播的協議，當前主流的有兩類： 一類是基于切片的，利用傳統CDN分發網絡的（比如HLS，DASH），另一類是流式的RTMP/HTTP-FLV或WebSocket的方式。

HTML5標準規定了瀏覽器可以通過video標簽完成視頻播放的功能。Video標簽本身并不支持流式的播放（不過移動端對HLS直播支持得還不錯了），但是可以通過MSE（Media Source Extension）動態的給video標簽喂分片mp4數據，來實現等效的直播功能。常見的播放HTTP-FLV直播流就是采用這種方式。這種方式的優點就是能保持較低的延時，也無需安裝插件，還能利用系統播放的硬件加速機制，獲得較高的解碼性能。如下圖就是通過FLV.js的模式播放視頻。

Video標簽支持的協議和編解碼器（Codec）是比較有限的。支持的協議和容器層面還可以通過JavaScript + MSE的方式轉換成video標簽支持的格式，但是對于不支持的編碼器類型就無能為力了。幸運的是瀏覽器提供了一種Web Assembly的機制，能把其他語言的代碼編譯成可供JavaScript引擎執行的Assembly代碼。這樣對于不支持的音視頻編解碼器，都可以通過Web Assembly進行軟件的解碼，得到原始的YUV數據和PCM數據，再結合WebGL和WebAudio技術，就可以實現完整的播放功能。

這種方式的優點是能支持幾乎所有的編碼類型，缺點則是需要軟件方式來解碼，有相當大的CPU開銷。目前W3C也在推進WebCodec，未來可以通過WebCodec實現解碼能力，也能充分利用系統的硬件加速，彌補這種模式帶來的缺點。

• 2）實時音視頻對講（RTC）

RTC技術在互聯網上已經得到了廣泛的應用（短視頻、直播、視頻會議等等），已經徹底改變了我們的生活。在物聯網領域，人們也有利用IOT設備進行實時音視頻通話的需求。RTC技術目前已經算比較成熟了，但是嵌入式設備的計算力和內存資源就比較有限，無法簡單把現有技術移植過來。比如音頻的3A算法就比較消耗CPU計算，通常在嵌入式設備上的3A算法需要做特別的優化和裁剪。

帝視的RTC功能，支持1對1模式的對講（全雙工），也支持多對多模式的。對于一些需要與傳統固話打通的場合，帝視還支持與PSTN固話網絡的打通，可以通過嵌入式設備撥打傳統的電話。

• 3）圖像和聲音信號處理算法

畸變矯正

所有光學相機鏡頭都存在畸變的問題，畸變屬于成像的幾何失真，它是由于焦平面上不同區域對影像的放大率不同而形成的畫面扭曲變形現象，這種變形的程度從畫面中心至畫面邊緣依次遞增，主要在畫面邊緣反映得較明顯。對于變焦鏡頭畸變的問題尤其嚴重，一般在廣角端拍攝時，往往會使畫面邊緣向外凸起，稱之為桶形畸變;用遠攝端拍攝時，畫面邊緣經常會向內凹進，稱之為枕形畸變。畸變會引起成像時的畫面變形，大多數時候輕微的畸變并不會對畫面質量有太大影響，但某些應用可能對畸變比較敏感，比如翻拍資料、拍攝建筑物等規則物體，都希望畸變不要太嚴重，否則會明顯歪曲拍攝實物的幾何特征。

為減小畸變，可以通過算法對畸變進行反向變換糾正。帝視監控 SDK播放端提供畸變矯正算法，支持多種畸變模式的校正，并且可以根據實際情況對畸變校正參數進行微調，從而達到最理想的效果。

移動偵測

許多場景下監控畫面是保持靜止不動的(比如無人的場景)，但是攝像頭還是保持視頻編碼和對視頻流的存儲。為了節省存儲和傳輸成本，可以采用畫面的移動偵測技術，只在有畫面有變化時才開啟錄像。對于大部分場景，能極大的節省存儲和傳輸成本。為了節省開銷，一般需要嵌入式系統提供一路小分辨率的視頻流來進行移動偵測算法。

聲音變聲

對于安防場景的攝像頭或可視門鈴，女主人有變男聲來威懾壞人的需求。帝視的SDK提供了變聲的算法，能把女聲變成男聲。如果客戶有自己的算法，也可以通過帝視提供的前置處理接口，以插件注入的方式來做自定義的一些算法處理。

聲波配網

對于嵌入式設備，對設備進行配網是一個比不可少的操作。通常配網方式有AP配網、聲波配網、藍牙配網、二維碼配網等多種方式。對于聲波配網，帝視SDK提供把配網信息打包到聲音信號和從聲音信號里恢復原始配網信息的功能。

5. 廣泛的第三方標準支持

• 1）帶屏音箱的支持(Echo Show 和 Google Home 支持)

對于海外售賣的攝像頭設備，如果希望在亞馬遜電商平臺得到推薦，必須支持 WWA(Work With Alexa)，類似的谷歌也有Google Home 的帶屏音箱。支持帶屏音箱使得用戶可以通過語音交互控制攝像頭設備，讓攝像頭的監控內容顯示在屏幕上。有些設備還能支持雙向的視頻通話，極大的豐富了應用場景。

與帶屏音箱打通通常有兩種實現方式: 一種實現在設備端，另一種實現在云端。實現在設備端需要硬件設備有更多的資源，這會增加對應的硬件成本。實現在云端則比較靈活，也方便后期擴展。關鍵的要素就是用戶實際的使用量，如果用戶頻繁使用此項功能，帶來較多的流量，那么放在設備端實現就比較合適；如果使用頻度低，那么放在云端實現就是一個不錯的選擇。帝視當前已經實現了云端的支持。設備端在成本配置允許的情況下，也可以通過集成對應的 SDK 來實現對帶屏音箱的支持。

• 2）視頻監控的國標（GB28181）

GB28181的全稱是“公共安全視頻監控聯網系統信息傳輸、交換、控制技術要求”，目前廣泛應用于政府項目中。GB28181規定了城市監控報警聯網系統中信息傳輸、交換、控制的互聯結構、 通信協議結構，傳輸、交換、控制的基本要求和安全性要求，以及控制、傳輸流程和協議接口等技術要求，解決了不同的硬件廠商、集成商以及各種應用系統間監控數據的接入、交換與控制問題。凡是符合國標標準的攝像頭或NVR設備可以無縫的接入到國標管理平臺。如果設備想要支持GB28181標準，只需要集成帝視的設備端SDK。

• 3）ONVIF

ONVIF（開放式網絡視頻接口論壇）是一個全球性的開放式行業論壇，其目標是促進開發和使用基于物理IP的安全產品接口的全球開放標準。ONVIF創建了一個視頻監控和其他物理安全領域的IP產品如何進行相互通信的標準，旨在實現跨生產商的網絡物理安全產品之間的互操作性。帝視對ONVIF的支持類似GB28181，這里不再贅述。

6. 端到端的數據安全

在大數據時代，數據的安全性不言而喻。傳統的視頻監控只是運行在局域網或專網環境，面臨的安全威脅并沒有那么大。帝視提供的服務則是面向互聯網的，在數據安全方面需要更加嚴格的保護。對數據的保護離不開加密技術，目前大部分應用都采用信道加密技術（比如TLS、HTTPS）來保障數據不被嗅探和篡改。通常來說，對一個龐大的系統，信道加密技術只應用于一個節點與另外一個節點間的通信，數據在節點內部，還是以明文的方式存在與被處理的。在有“內鬼”的情況下，還是無法保障數據的安全。除了信道加密，帝視服務還采用了“端到端”的信源加密方式。秘鑰由業務方來管理，帝視服務并不接觸和存儲數據加密秘鑰，從根本上解決了數據安全問題。

四、視頻與物聯網的未來

360智匯云物聯網視頻解決方案-帝視平臺，從用戶的痛點出發，結合360多年的技術積累，打造了物聯網視頻應用的底層基礎設施。通過使用帝視的服務，客戶從技術密集與重資產的視頻服務中解放出來，可以更好的專注與自己的業務。帝視的增值服務，也讓硬件廠商有了更多的獲利空間。

視頻已經引領了消費互聯網的一次信息革命，同樣在不遠的將來，視頻也會帶來物聯網領域的信息革命。物聯網使得信息從虛擬空間延伸到物理空間，攝像機代替了人類的眼睛與耳朵，AI技術代替了人類的大腦，讓機器以人類的感知和理解方式去看這個世界，與人類交互，智能就在我們身邊！

原文：

https://zyun.360.cn/blog/?p=799