一、背景

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

1. 家用攝像頭的聯(lián)網(wǎng)功能是剛需

十多年前，攝像頭還是主要用在安防監(jiān)控領(lǐng)域。主要應(yīng)用的場合一般是公共場所或?qū)Π踩筝^高的地方。隨著智能家居的普及，家用攝像頭進入大眾的視野。家用攝像頭解決的用戶需求主要是看家、看老人、看小孩、看寵物。而這都需要能讓用戶在任何時間、任何地點，通過互聯(lián)網(wǎng)就能方便的訪問到家里攝像頭設(shè)備。

2. 視頻監(jiān)控“聯(lián)網(wǎng)”是實現(xiàn)數(shù)字化和智能化的前提

隨著產(chǎn)業(yè)互聯(lián)網(wǎng)的發(fā)展, 越來越多的傳統(tǒng)企業(yè)在做數(shù)字化、智能化轉(zhuǎn)型。視頻監(jiān)控是其中一個核心的要素，因為視頻能直觀的記錄完整場景、保留所有的信息，是單純的傳感器所不可比擬的。即使因為當前的技術(shù)限制、業(yè)務(wù)關(guān)注點等原因沒有提取所有的相關(guān)信息，只要保存原始的監(jiān)控視頻數(shù)據(jù)，在未來還是可以完成追溯和提取分析的功能。傳統(tǒng)的視頻監(jiān)控大多是基于局域網(wǎng)或?qū)Ｓ镁W(wǎng)絡(luò)的，必須進行改造。

3. 云服務(wù)能力是硬件廠商的痛點

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

• 1）技術(shù)和財力上無法支撐技術(shù)密集、重資產(chǎn)的視頻云服務(wù)

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

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

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

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

4. 視頻對傳統(tǒng)物聯(lián)網(wǎng)云帶來的挑戰(zhàn)

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

二、帝視：360智匯云物聯(lián)網(wǎng)場景下的視頻解決方案

1. 帝視提供的基礎(chǔ)能力

對于視頻類物聯(lián)網(wǎng)設(shè)備，常見的需求有以下的幾類，帝視 SDK 能覆蓋下列所有的視頻需求

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

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

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

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

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

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

• 4）遠程訪問設(shè)備上的文件

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

• 5）云存上傳與管理

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

• 6）行業(yè)標準支持

由于硬件廠商眾多，為了讓各家的產(chǎn)品的視頻數(shù)據(jù)能互聯(lián)互通，目前行業(yè)內(nèi)形成了多個標準。帝視提供對應(yīng)的SDK來支持第三方的標準。目前主流的GB28181、ONVIF、RTMP、RTSP協(xié)議都支持。

• 7）其他增值服務(wù)

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

2. 帝視的組成框架圖

帝視服務(wù)是一個PaaS服務(wù)，提供全平臺的終端SDK和云端服務(wù)?？蛻粜枰虚_發(fā)能力，把帝視的SDK集成到自己的應(yīng)用里。帝視封裝了幾乎所有與音視頻相關(guān)的部分，使得客戶不需要關(guān)心底層復(fù)雜的音視頻的存儲、傳輸、播放，就能享受到帝視服務(wù)的極致視頻體驗。

3. 典型應(yīng)用場景

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

帝視還可以應(yīng)用于NVR設(shè)備上，使得傳統(tǒng)的攝像頭接入NVR后，也可以在公網(wǎng)上被安全的訪問，特別適合利舊的場景。

三、帝視服務(wù)的關(guān)鍵技術(shù)

1. 強大的私有傳輸協(xié)議和分發(fā)網(wǎng)絡(luò)

• 1）P2P 技術(shù)節(jié)省90%+的服務(wù)器帶寬

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

• 2）弱網(wǎng)表現(xiàn)強勁的私有傳輸協(xié)議

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

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

• 3）全球覆蓋的Relay中繼網(wǎng)絡(luò)

在國內(nèi)市場趨向飽和的情形下，越來越多的硬件廠商把目光轉(zhuǎn)向了海外的市場。為了實現(xiàn)海外的覆蓋，帝視的Relay中繼以及P2P服務(wù)都進行了全球部署。未來根據(jù)業(yè)務(wù)需要，也會拓展覆蓋的地區(qū)和規(guī)模。

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

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

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

2. 支持多種低功耗方案

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

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

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

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

• 1）單系統(tǒng)方案

單系統(tǒng)方案一般采用RTOS或LiteOS系統(tǒng)方式，模塊功能根據(jù)需要進行裁剪和移植。單用單系統(tǒng)的方式一般也會只在需要的時候才去加載特定的功能模塊，盡量減少不必要的開銷。同時對于?；睢拘延|發(fā)機器都需要做專門的優(yōu)化。

• 2）雙系統(tǒng)方案

雙系統(tǒng)方案結(jié)合了通用操作系統(tǒng)和專用的系統(tǒng)兩者的優(yōu)點，如下圖所示：

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

3. 多級存儲技術(shù)

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

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

• 1）設(shè)備端卡錄

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

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

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

全時段錄像 vs. 事件觸發(fā)型

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

磁盤空間管理

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

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

• 2）NVR本地存儲文件系統(tǒng)

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

機械磁盤的一個顯著特性就是存在尋道時間，導(dǎo)致隨機訪問和順序訪問有這極大的性能差異。機械盤順序讀寫的吞吐是優(yōu)于隨機讀寫的。雖然對于單路視頻流錄像而言，是滿足順序?qū)懭氲模侨绻芏嗦?比如 16 路、32 路)同時寫入還是會讓磁頭反復(fù)尋道。磁盤本身的 NCQ 技術(shù)雖然能緩解一部分，但是無法從根本上解決。

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

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

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

• 3）云端存儲與云存服務(wù)

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

把攝像頭的實時視頻數(shù)據(jù)上傳到云端，有多種實現(xiàn)方式，對應(yīng)帝視SDK的多種云存模式

流式傳輸 vs. 切片文件

攝像頭的視頻流本身是流式的，但是一般的云存儲都是對象存儲，并不是一個無始無終的流式文件，必須要把流式的視頻流切割成一個個的文件。通?？梢园蚜魇降奈募懈詈蟠鎯Τ商囟ǖ娜萜鞲袷?，比如MP4和TS。因為MP4文件的寫入通常涉及到索引的處理，需要seek到文件頭進行索引位置的更新操作，并不適合邊傳輸邊寫入。TS則比較方便，無需索引位置的更新，不過TS文件的overhead相對mp4來說要高一些。

設(shè)備端直接上傳 vs. 云端切片上傳

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

云端Meta信息存儲

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

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

4. 完善的視頻能力

• 1）靈活的播放能力

對于基于攝像頭類的應(yīng)用場景，視頻內(nèi)容的實時觀看與錄像回溯是最基礎(chǔ)的功能。但是對于物聯(lián)網(wǎng)場景，比如安防監(jiān)控的視頻播放、家用攝像頭的視頻播放與傳統(tǒng)場景不太一樣的地方就是能在公網(wǎng)上遠程觀看視頻，并且利用P2P技術(shù)節(jié)省大量流量帶寬。

實時監(jiān)控播放

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

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

錄像視頻播放

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

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

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

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

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

網(wǎng)絡(luò)與播放的解耦

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

Web端無插件播放H265監(jiān)控視頻

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

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

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

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

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

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

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

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

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

畸變矯正

所有光學(xué)相機鏡頭都存在畸變的問題，畸變屬于成像的幾何失真，它是由于焦平面上不同區(qū)域?qū)τ跋竦姆糯舐什煌纬傻漠嬅媾で冃维F(xiàn)象，這種變形的程度從畫面中心至畫面邊緣依次遞增，主要在畫面邊緣反映得較明顯。對于變焦鏡頭畸變的問題尤其嚴重，一般在廣角端拍攝時，往往會使畫面邊緣向外凸起，稱之為桶形畸變;用遠攝端拍攝時，畫面邊緣經(jīng)常會向內(nèi)凹進，稱之為枕形畸變?；儠鸪上駮r的畫面變形，大多數(shù)時候輕微的畸變并不會對畫面質(zhì)量有太大影響，但某些應(yīng)用可能對畸變比較敏感，比如翻拍資料、拍攝建筑物等規(guī)則物體，都希望畸變不要太嚴重，否則會明顯歪曲拍攝實物的幾何特征。

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

移動偵測

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

聲音變聲

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

聲波配網(wǎng)

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

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

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

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

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

• 2）視頻監(jiān)控的國標（GB28181）

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

• 3）ONVIF

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

6. 端到端的數(shù)據(jù)安全

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

四、視頻與物聯(lián)網(wǎng)的未來

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

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

原文：

https://zyun.#/blog/?p=799