在安防領域，超高清視頻監控有著非常值得期待的應用前景。但只有解決了阻礙應用的傳輸、算力、算法、存儲、安全等幾個問題之后，應用的前景才會變得清晰起來。另一方面，傳統網絡正在發生天翻地覆的改變，計算和存儲能力提高，算法進一步硬件化智能化，安全問題也從未像今天一樣成為國家意志，凡此種種為超高清視頻監控的技術突破帶來了光明的前景和奮進的動力。
1.傳輸問題
超高清視頻監控面臨的個問題是傳輸問題。由于4K視頻超大的分辨率，對于25fps的幀率來說，在相同編碼規格下，其碼率約為高清視頻(1080P)的4倍以上，對于傳輸的要求也相應提升了數倍。即使采用H.265等較為*的編碼方式，由于超高清視頻在色深、幀率、分辨率等方面的改進，其傳輸量也是不可小覷的。到了8K超高清視頻的時代，其傳輸量又會有成倍的增加。因此，增加帶寬，即增加端側的吞吐能力和增加中間鏈路的傳輸能力是超高清視頻監控面臨的首要問題。
(1)增加端側的吞吐能力
端即超高清視頻的接收端和發送端，增加兩端的網卡上下行能力極為關鍵。上下行能力受以下因素制約：網卡性能、緩沖區大小與調度機制、網絡協議棧工作效率、超高清視頻監控應用進程本身的吞吐能力、視頻接收與發送的策略等。
①網卡性能優化
為了保證監控視頻傳輸質量，我們以單千兆卡60%的有效上下行傳輸率計算。在單千兆卡的情況下，對于H.264MainProfile編碼的4K超高清視頻，即使其碼率只有1080P的4倍也會接近30Mbps，因此單千兆網卡只能承載20路左右的4K超高清視頻。這對于瀏覽客戶端可能問題不大，但對于流媒體服務器是遠遠不夠的。因此，從千兆卡升級到萬兆卡，或者多張千兆卡綁定以擴展上下行能力就顯得尤為重要。
另一方面，對于諸多由軟件完成的傳輸功能，例如網絡包軟校驗、加解密、DPI等功能*可以“卸載”到硬件中執行，這就是我們耳熟能詳的硬件卸載加速技術。通過SOC的方式將這些功能以硬件語言設計和描述，在SOC內實現ASIC電路是一種明智之舉。
②緩沖區優化
視頻監控的網絡傳輸應用中流媒體服務器占了流量的大頭。因此流媒體服務有針對性地改進機制和提升性能就顯得越發必要。緩沖區作為網卡與操作系統、應用軟件交互的中間媒介理應做出相應的改進。
a.HugePage機制：操作系統中內存頁面的分配粒度是4KB，對于超高清視頻這顯然是不夠的，因此有選擇性地啟用大內存頁機制甚至巨頁機制，使其分配的粒度達到若干MB甚至1GB，以減少內存頁倒換帶來的系統開銷，這無論對于發送端還是接收端都具有很重要的意義。
b.DMA機制：DMA即直接內存存取機制。通過DMA可以摒棄傳統的“網卡緩存->主存->CPU緩存”的傳輸路徑，轉而通過DMA控制器建立網卡緩存到CPU三級緩存之間的映射實現數據的快速交換。由于繞過了主存讀寫這個速度較慢的步驟并省略了2次PCI-E總線的IO，因此讀寫速度會大大加快。
③網絡協議棧優化
傳統網絡協議棧是以內核態驅動的方式存在于操作系統中的，其關鍵工作機制是中斷響應、延遲過程處理、通用包處理。
中斷響應：傳統網絡協議棧驅動以網卡的中斷機制為基礎，網絡包的到達和發送完成均以中斷機制通知上層網絡協議棧，以便協議棧驅動繼續處理接收和發送。
延遲過程處理：協議棧驅動響應中斷后，并不是將包的收取或發送處理包含在中斷處理例程中占用中斷時間，因為中斷的優先級較高，如果中斷占用的時間太長會影響其他優先級線程的執行，因此中斷處理例程將具體的收取/發送等事務性工作放在DPC(延遲過程調用)隊列中，待中斷優先級下降時才處理，這樣就減少了中斷打擾占用的時間。
通用包機制：網絡協議棧是瞄準通用型網絡包處理的，因此對于OSI模型的每層協議都會進行相應的處理和校驗，這比較適合流量不大包類型各異的情況。而在高清視頻流媒體服務器上流量較大，且傳輸的一般為信令報文和視頻包，其協議格式和封裝方式固定。
上述機制在一定程度上降低了協議棧的處理效率。針對超高清視頻流媒體服務器，可以采用改進的網絡協議棧對傳統協議棧進行旁路化改進，比如定制專門針對流媒體傳輸的協議棧驅動，或者嫁接高速傳輸設備的協議棧驅動。DPDK(數據平面開發套件)框架就是一個較好的選擇。DPDK是一種基于IntelX86/X64平臺的網絡數據包處理框架，也是一套數據包旁路化處理的方案，具有很高的IO處理速度，多用于SDN高速交換機和路由器的轉發驅動框架，具有以下特點和機制：
a.UIO機制：UIO(UserspaceI/O)機制將小部分驅動運行在內核態空間(硬中斷只能在內核態空間處理)，大部分運行在用戶態空間以實現旁路化機制。
b.SIMD機制：DPDK框架采用批量方式同時處理多個網絡數據包，基于向量式編程，一個周期內對所有網絡數據包進行處理，加大了處理吞吐量。
c.緩存優化機制：采用Cacheline對齊、Cache數據預取等策略加快緩存中數據的讀取和處理速度。
d.PDM機制：PDM(PoolModeDriver)機制拋棄中斷模式，改為基于中斷+輪詢的方式收包，避免了中斷開銷。
e.無鎖循環隊列機制：支持單生產者入列、單消費者出列和多生產者入列、多消費者出列的操作，因此可以提高傳輸效率并保證數據同步。
f.處理器親和性機制：利用處理器親和性(CPUAffinity)機制將IO線程綁定到若干個CPU核上，以此減少線程調度和切換從而降低切換開銷，同時由于線程被綁定在固定的CPU核上，CPU緩存的命中率大大提高。
g.多隊列機制：通過多隊列網卡驅動的支持，將各個隊列綁定到不同的CPU核上，以滿足網卡高吞吐的需求。
h.DDIO機制：DDIO(DataDirectIO)是Intel提出的技術，允許網卡與CPU通過LLC(lastlevelcache)直接交換網絡數據，從而繞過主存，既縮短了交互流程，也提升了交互的速度。該技術類似DMA機制，但比DMA具有更高的效率。
i.硬件加速機制：將基礎性重復性的軟事務(例如計算分析類任務、TCP組包類任務和TCP分段任務等)“卸載”給硬件完成以加快處理速度。
除了網絡傳輸外，在視頻存儲領域亦可以采用SPDK(StoragePerformanceDevelopmentKit)框架以代替傳統存儲協議棧驅動框架，SPDK不失為一種效率成倍提升的有效手段，且該框架更是當今非常流行的軟件定義存儲的加速器。
④應用進程軟件調優
除了上述幾種機制外，還可針對超高清視頻的特點對傳輸節點進行改進。例如基于視頻包封裝協議較為固定的特點，會話協商報文可通過傳統協議棧流轉，而流媒體包則通過DPDK驅動進行傳輸，并對DPDK進行相應的裁剪，只需適應TCP、UDP、SCTP這些四層協議不同的封裝要求即可。
同時也可以其他采用軟件調優的思路，例如：
軟件架構采用去中心化的設計思想，盡量避免全局共享，以減少全局競爭和失去橫向擴展的能力；
在NUMA架構下不跨Node使用內存，以避免內存遠程訪問；
不使用慢速API；
視頻應用進程不在IO線程中承擔過多任務，若無特殊要求更應避免任何形式的阻塞。
(2)增加中間鏈路的傳輸能力
隨著5G的發展和成熟，以SDN/NFV、*6為特征的新一代網絡已悄然落地，這為接入網、城域網和核心網傳輸能力的增加提供了契機，更為超高清視頻的傳輸提供了擴容手段。
首先，*6的普及可以有效地減少NAT等傳統IP擴容設備的部署，極大減少了在互聯網環境下的傳輸瓶頸和限制。
再者，SDN(軟件定義網絡)隔離了傳輸的數據面和控制面，一方面解耦了軟件與硬件的綁定，更重要的是交換設備本身不再承擔找端口找路由等邏輯判斷功能，極大地釋放了交換設備的IO能力。SDN應用層可以對超高清視頻的Qos業務進行定制化處理，采用交換機流表項的方式代替了原先通過MPLS實現的Qos業務，省略了包封裝和解封裝的開銷，提高了傳輸效率。
后，NFV(網絡功能虛擬化)支持在通用平臺上實現以虛擬化為載體的網絡業務功能，進一步釋放了通用計算平臺的計算力。
2.算力問題
對于超高清視頻監控而言，算力問題就是編解碼的效率問題。由于巨大的分辨率，即使采用H.265的壓縮標準，其存儲和網絡開銷亦是不可忽視的。但提高壓縮標準必然帶來編碼端與解碼端“編”和“解”的算力開銷。在此我們重點討論一下解碼能力。
針對普通的解碼端(包括解碼器、PC端、移動端與機頂盒端等)，在當前的配置下解碼4K甚至8K超高清視頻是非常吃力的，這主要由以下原因造成：
(1)超高清視頻源本身壓縮標準、碼率、分辨率、幀率都非常高，由此帶來了解碼與時間同步等問題的壓力也很大。
(2)大部分解碼端性能都不是特別高，配置專門的高性能顯卡非常昂貴。特別是移動端算力尚顯單薄的情況下，高負荷的解碼壓力勉為其難。
(3)操作系統對于超高清視頻解碼后的渲染事務尚未擔負起相應的責任，除了硬件上的優化，驅動軟件特別是顯卡驅動與顯示框架的優化也非常重要。
鑒于以上原因，在處理超高清視頻時，可以有針對性地對解碼端進行性能加固。
•配置高性能顯卡是直接有效的手段。例如Nvidia的顯卡對于解碼與編碼均具備廣泛的加速支持，GPU性能和并行計算能力也非常強悍。尤其是顯卡本身的驅動較好地處理了顯存與主存之間的IO交互，使得解碼與渲染可以處于同一個渲染管線環境，更加速了超高清視頻的處理速度。
•基于專有廠家芯片的編解碼加速支持也是一個非常好的選擇，這種方案也是片上系統解碼+渲染的方案。例如Intel針對其核芯顯卡的QSV(高速圖像同步轉碼技術)加速技術就是基于普通的被封裝到CPU芯片中的HDGraphics系列核芯顯卡的。這種方式可以在一定程度上提高超高清視頻的解碼處理能力。
•對于操作系統顯示驅動體系的軟件改進是超高清視頻渲染加速的有效手段。例如針對Windows新的圖形驅動模型WDDM(WindowsDisplayDriverModel)的渲染改進與加速，特別是針對DirectDraw基礎庫(主要用于播放視頻)的硬件加速支持，也是一個不容忽視的方面。
現階段支持軟解碼的主流開源庫是FFMPEG，而FF對于編解碼的硬件加速也有很好的支持。例如對于IntelQSV技術的支持已經融入到FF中(集成了Intel的MediaSDK)并體現出了良好的性能(解碼時顯存占用會稍大)。而FFmpegCUVID(基于CUDA的視頻解碼庫)/NVECN/CUDA部分也分別集成了支持硬件加速的解碼、編碼以及部分CUDA加速的諸如Scaling這樣的過濾器機制。
除此之外，還有若干種獨立于平臺的優化方案，包括：
OpenMax：這是由KhronosGroup制定的開放多媒體加速器，包括音頻、視頻和圖像處理的全套API。使用時無需關注底層邏輯，減少了流媒體軟件的設計流程，易于擴展，且*免費。
Vulkan：這是由KhronosGroup制定的下一代開放的圖形顯示API，與OpenGL相比具有更簡單的顯示驅動層，同時支持跨平臺特性、多線程特性和預編譯的Shaders。
OpenCL：作為異構高性能計算的標準框架，OpenCL提供了基于任務和基于數據兩種并行計算機制，不僅于圖形計算。不過FFMPEG僅僅優化了AVFilter(過濾框架)部分，主要用于硬件加速轉碼的場景下。
除了解碼和渲染，還要考慮播放問題。例如4K超高清視頻播放需要HDMI1.4a及以上的接口，HDMI1.4支持10.2Gbps的帶寬，只夠支持24fps、25fps、30fps的UHD4K的播放。因此未來要加快發展大帶寬達到18Gbps、可播放4K分辨率和3D視頻的HDMI2.0標準。
3.安全問題
安全問題并不是超高清視頻監控領域*的問題，所有信息技術領域均須重視各種安全問題。安全問題可分為以下幾個領域：系統安全、數據安全、網絡安全和應用安全。對于超高清視頻監控我們需要關注以下內容。
(1)系統安全
面臨服務器硬件、操作系統和監控終端的三重安全威脅。對于服務器系統，幽靈(Spectre)與熔斷(Meltdown)作為處理器的巨大漏洞雖然已被修復，但是包括修復補丁在內還有多少處理器的0-Day漏洞尚未可知。操作系統的漏洞就更多了，2017年爆發的“永恒之藍”系列漏洞直接被黑客利用開發出了Wannacry*，可怕場景至今歷歷在目。而對于監控終端，其操作系統日益開源化、處理器平臺日益通用化，這也為各種物聯網設備、工控設備的Rootkit入侵提供了便利。
針對上述情況，除了要對操作系統進行安全加固外，還要針對監控終端的操作系統進行全流程控制。可以采用可信計算的思想對操作系統的啟動進行安全度量。例如CPU芯片中植入可信計算基TCB，在系統啟動的不同階段進行層層嵌套式的安全度量。
1)BIOS以芯片中的TCB為標準進行度量；
2)BIOS可信后以上述度量結果為新的TCB度量主引導區MBR；
3)MBR可信后以上述度量結果為新的TCB度量活動分區OBR。
如此層層度量，雖然啟動會略慢，但從一定程度上加固了服務器和終端的操作系統安全，是值得也是必要的。
(2)數據安全
GB35114作為視頻監控領域數據安全的*和探路人，已經開始在行業內實踐落地，并已開始構筑生態體系。對于超高清視頻監控，符合GB35114規范的B級和C級標準必然意味著更大的加解密算力需求。特別是對于C級標準視頻內容本身的加解密，其開銷十分巨大。
基于此，要研究針對超高清視頻本身的數據安全機制。對于加解密的算力需求，應將其“卸載”到專有芯片(例如ASIC)中實現。針對非對稱型加密機制，亦可通過硬件+軟件的方式共同實現。同時也可以采用約定的方式抽取若干視頻幀進行加解密以降低算力開銷。
(3)網絡安全
在超高清視頻監控系統中，要加強抵御DDOS攻擊的能力和手段，增加數據擺渡和校驗機制。特別是在超高清視頻流量巨大的情況下，這對于數據擺渡設備是一個重大考驗。除此之外，通過回聲技術的攝像機的安全準入系統也應視情況部署和使用。
(4)應用安全
在視頻監控領域也應重視應用軟件本身的漏洞和防護。針對緩沖區溢出漏洞、數字溢出漏洞、惡意模塊注入、SQL注入漏洞、Bypass漏洞等要有檢測和防護的措施，以保證整個應用系統的穩定，不能讓這些漏洞成為信息系統中病毒與APT(可持續威脅)傳播的跳板。
