随着智能家居与物联网的普及，网络摄像头（IPC）逐步渗透到家庭、幼儿园、小店商铺等场景；国家推进的天网工程、雪亮工程让公共场所都安装上了监控摄像头；数字化与智能化的趋势也让园区、学校、工厂遍布视频摄像头。除了典型的安防监控摄像头，还有越来越多的视频类IOT新产品涌向市场（例如可视门铃、行车记录仪、可视门禁等）。5G时代到来后，视频在物联网场景下的应用也会越来越丰富。
1. 家用摄像头的联网功能是刚需
十多年前，摄像头还是主要用在安防监控领域。主要应用的场合一般是公共场所或对安全要求较高的地方。随着智能家居的普及，家用摄像头进入大众的视野。家用摄像头解决的用户需求主要是看家、看老人、看小孩、看宠物。而这都需要能让用户在任何时间、任何地点，通过互联网就能方便的访问到家里摄像头设备。
2. 视频监控“联网”是实现数字化和智能化的前提
随着产业互联网的发展, 越来越多的传统企业在做数字化、智能化转型。视频监控是其中一个核心的要素，因为视频能直观的记录完整场景、保留所有的信息，是单纯的传感器所不可比拟的。即使因为当前的技术限制、业务关注点等原因没有提取所有的相关信息，只要保存原始的监控视频数据，在未来还是可以完成追溯和提取分析的功能。传统的视频监控大多是基于局域网或专用网络的，必须进行改造。
3. 云服务能力是硬件厂商的痛点
对于摄像头、NVR等与视频相关的硬件厂商而言，竞争的点不再局限于硬件的品质、功能、成本，云能力成为一个至关重要的一个环节。硬件厂商感受到行业趋势的变化，积极的去拥抱新的变化，但是也碰到一些困难。
视频技术涉及网络传输、视频编解码、图像音频信号处理、媒体协议与容器、视频播放与控制等诸多技术，是一个技术密集型的领域。视频领域的专业人才比较稀缺，而把视频技术应用在嵌入式和物联网设备领域，更加提升了对技术人员的挑战。而且硬件厂商的技术人员的技术栈多在硬件和终端技术上，在云服务上几乎无任何积累。
另外，云计算服务一般都是重资产。一方面为了解决全网的网络覆盖问题，让每个用户都能有好的体验，就需要在全球部署很多IDC节点。另一方面，视频数据的数据量大，对云服务的规模要求高。硬件厂商大部分都是中小规模的公司，根本不具备自己建设大规模视频云服务的能力。
对于硬件厂商而言，属于传统制造业，主要的利润来源是硬件的一次性售卖。随着竞争的日益加剧，硬件厂商毛利空间越来越小，硬件厂商也迫切需要寻找新的获利方式。随着云计算的发展与智能化的趋势，给了硬件厂商新的机遇。相比一次性的硬件售卖，提供增值云服务可以获得更持久、更稳定的收入来源。
4. 视频对传统物联网云带来的挑战
传统的物联网云，解决了设备接入、设备管理、数据采集、OTA 升级等基础功能。通信的数据量一般来说相对较小，不会对物联网云带来较大的影响。但对于视频类的设备，视频的数据量巨大，传统的物联网云的数据通道无法承载海量的视频类数据。泛娱乐场景，已经有通用的 CDN 和存储基础设施来支持，但是物联网的视频有其特殊的场景需求，需要有专用的系统和平台解决这一垂直领域的各类问题。360 物联网视频服务（
https://zyun.360.cn/product/iot）就是为了解决这个场景下的问题，从而成为物联网领域视频的底层基础设施。
1. 帝视提供的基础能力
对于视频类物联网设备，常见的需求有以下的几类，帝视 SDK 能覆盖下列所有的视频需求
无论是家用摄像头还是监控类摄像头，用户都有远程随时随地查看当前实时视频的需求。用户的移动设备的网络可能与设备所在的网络不在同一个运营商，甚至都不一定在同一个地域。如何让用户快速、流畅的观看实时视频就成了核心要解决的问题。除了能看到画面，对于支持云台的摄像头，还需要可以通过远程的操控控制摄像头的转动和对焦，方便用户实时的捕捉和跟踪动态的目标物体。
一般的摄像机都可以带本地的存储卡，能存储一段时间的完整录像。通常在发生了特定的事情或需要追溯时，用户需要远程查看存储在摄像头存储卡上的录像内容。由于录像的时间比较长，需要能方便准确的定位到对应的时间段。还要提供快进、后退、倍速、跳帧播放等高级的功能提升追溯的效率。对于NVR的场景，卡录则对应NVR上的本地存储。
视频类摄像机除了能采集视频外，一般还带有麦克风和扬声器。这样就使得远程的用户可以和设备端的用户进行实时的互动。通常有半双工和全双工两种方式。如果设备自身带显示屏幕，还可以进行双向的视频通话。RTC功能提供低延迟的传输与3A算法（回声消除、降噪、自动增益控制），对于一些配置比较低的设备需要硬件或厂商提供3A算法的软硬件实现支持。
对于 NVR 设备和NAS 设备，设备侧存在很多以文件方式存储的内容(如事件视频、相册内容)，远程的用户也需要通过简单的方式访问到这些内容，而不需要把这些内容上传到云端。
除了设备上的存储卡，还可以把视频录像上传的云存储上，解决设备损坏、暴力拆除的问题，在一些紧急事情的场景，也能记录后重要的关键画面(设备可能被犯罪分子先破坏)。视频监控内容上传到云端存储后，还可以开通更多的增值服务，进行 AI 分析，使得安防事件报警更加精准。
由于硬件厂商众多，为了让各家的产品的视频数据能互联互通，目前行业内形成了多个标准。帝视提供对应的SDK来支持第三方的标准。目前主流的GB28181、ONVIF、RTMP、RTSP协议都支持。
2. 帝视的组成框架图
帝视服务是一个PaaS服务，提供全平台的终端SDK和云端服务。客户需要有开发能力，把帝视的SDK集成到自己的应用里。帝视封装了几乎所有与音视频相关的部分，使得客户不需要关心底层复杂的音视频的存储、传输、播放，就能享受到帝视服务的极致视频体验。
3. 典型应用场景
帝视可以应用到所有带音视频采集的嵌入式设备上。除了常见的IPC摄像头外，像联网版本的行车记录仪、可视门铃、可视门锁、可穿戴设备（儿童手表、老人手表）等等都可以使用帝视的视频能力，让用户跨越时间和空间的限制，随时随地的以音视频的方式与设备进行沟通。近几年，低功耗品类的嵌入式设备也逐步流行，帝视也能支持多种低功耗方案。
帝视还可以应用于NVR设备上，使得传统的摄像头接入NVR后，也可以在公网上被安全的访问，特别适合利旧的场景。
1. 强大的私有传输协议和分发网络
不管是实时视频查看，还是存储卡录像的查看，数据都需要从设备端流向远程移动 App 上。如果所有的流量都走服务器的中转，那么这个带宽成本会巨大。360 视频云通过 P2P 技术，让移动终端用户和智能硬件设备间，通过点对点的链路进行通信，并利用 360 自研的私有传输协议做拥塞控制，即节省了服务器中转的带宽，同时保持了良好的传输效率，弱网下也能有良好的表现。正常情况下，90%以上的带宽可以走P2P 的方式，从而极大的节省了成本。另外，利用P2P技术，也可以实现用户到设备局域网的隧道(Tunnel)，可以让用户远程访问设备局域网内的其他网络服务。
帝视的私有传输算法在丢包率到达30%时，还能比较充分的利用带宽。而传统的TCP则对丢包特别敏感，随着丢包率的上升，吞吐量急剧下降。基于BBR算法的TCP或QUIC则相对表现好些，但是在超高丢包率的场景下表现也略差。（如下表）
表格：帝视私有传输协议与公开协议在弱网下的效果对比（条件： 5Mbps带宽，50ms延时）
在国内市场趋向饱和的情形下，越来越多的硬件厂商把目光转向了海外的市场。为了实现海外的覆盖，帝视的Relay中继以及P2P服务都进行了全球部署。未来根据业务需要，也会拓展覆盖的地区和规模。
未来越来越多的终端设备会携带AI算力，在数据采集到时间，就可以进行AI分析。对于AI提取到的检测结果（比如人脸识别信息），也需要有通道进行传递。通常AI检测的结果信息需要在视频播放时同步展示出来，比如需要在播放画面上用矩形框出检测到的人脸，并显示一些人脸属性信息。如果AI检测结果的信息与视频流是分开传输与存储的，就很难在播放时同步的展示检测结果信息。
帝视的SDK提供一个存储视频帧Meta信息的机制，可以为每一帧都存储一段任意大小的二进制数据，它和视频流信息是一起传输和存储的。在用帝视的播放器进行播放时，会把即将渲染的视频帧携带的Meta信息回调给业务层，供业务层自己解析出来进行叠加展示。
2. 支持多种低功耗方案
物联网设备的普及，除了基础的通信功能外，还受限与一些物理场景，比如供电、物理尺寸等。很多的应用场景无法保证长时间的物理供电，比如室外的一些设备、移动的设备等。一方面要保证整体功耗极低，使用电池就能满足较长的待机时间(通常几个月或一年以上)，另一方面又要保证无间断的工作，不能因为节省电量导致遗漏处理事件。
对于传统的一些物联网设备，可以通过改进无线通信方式、操作系统、采用低功耗芯片来解决低功耗问题。物联网场景下的无线通信方式通常有蓝牙、Zigbee、NBIot、zWave以及 WiFi 等多种方式。不同的无线通信方式有着不同的通信距离、通信速率和功率消耗。但对于视频类应用而言，需要的带宽和传输的数据量大，使得 Zigbee、zWave以及 NBIot 这些方式不能满足需求，而蓝牙也需要添加额外的网关才能接入互联网。
在系统和芯片选择上，有通用的操作系统(比如 Linux)和特定场合下使用的系统可供选择。通常来说通用的系统功能扩充方便，软件移植和维护也都比较简单，但对应的开销也会比较大。专用的系统(比如 RTOS)则简化了通用系统的很多功能，只保留了少且必要的部件，使得满足业务功能的同时，极大的降低的开销，但在软件移植和代码维护方面都有较大的难度。
帝视提供了单系统和多系统两种低功耗方案的支持
单系统方案一般采用RTOS或LiteOS系统方式，模块功能根据需要进行裁剪和移植。单用单系统的方式一般也会只在需要的时候才去加载特定的功能模块，尽量减少不必要的开销。同时对于保活、唤醒触发机器都需要做专门的优化。
双系统方案结合了通用操作系统和专用的系统两者的优点，如下图所示：
系统由两个部分组成，一部分是常驻的 RTOS 系统，维持很低功耗运行，同时监测传感器和远程的网络触发唤醒请求。当满足触发条件，比如有人经过智能可视门铃，或者用户通过 App 远程唤醒时，RTOS 系统再唤醒Linux 系统。Linux系统再来完成正常的业务功能。这种方案兼顾通用系统和专有系统的优点，既保证了软件移植和开发维护的效率，同时也达到低功耗的目标。
3. 多级存储技术
不管是传统视频监控领域还是逐步普及的家用网络摄像头，视频内容的录像存储都是一个比较有挑战的课题。传统的监控录像分为摄像机终端上的卡录、NVR上的存储两种场景。随着数字化和智能化的发展需要，越来越多的场景会把视频流实时的上传到云端进行存储。视频监控内容因为其数据量大、特殊的访问模式等因素，需要有针对性的进行设计。视频监控的存储系统是一个专门为垂直场景而设计的，根据视频数据的特性、存储介质的特性、访问模式等，针对场景做了很多Tradeoff，从而获得想要的表现。
在访问模式上，视频监控的录像存储只需要记录一次，而在使用的时候则可能被多次反复的读取。访问的pattern通常是从某个时间点按顺序提取数据，提取的粒度通常是某个视频通道，持续的时长则根据实际的场景情况有较大差异。如果读取是用播放器来播放，播放器还支持倍速、前进、回退、跳帧播放等。总体概括起来就是：小范围连续，大范围跳跃，按时间检索。
设备端的卡录是把录像数据存储到设备本地的存储卡上，当存储满后进行循环淘汰覆盖。始终保持的录像数据。例如一个16GB的卡，如果码率是512kbps，7x24小时录像，大约可以存储3天的时长。不管是FAT32还是ext3/ext4文件系统，都可以分为meta信息部分和真实的数据区部分。在读写频繁、设备掉电等多种情况下，会导致meta信息与数据的不一致。在普通pc和服务器上可以有一些fsck之类的工具进行修复。但对于嵌入式系统，我们需要尽量避免这种情况的出现。
对于存储设备，通常是按Sector/Block来管理的，一个逻辑文件通常包含很多个扇区，随着文件的创建、删除、修改，会让整个磁盘的扇区使用情况形成诸多碎片。碎片一方面会导致读取时带来随机访问降低吞吐，另外一方面在写入时也需要花费更多的时间来分配合适的扇区写入新的数据。另外，对于Flash存储设备，频繁或非法的读写还会导致进入写保护状态，无法继续写入录像数据。
基于上述的原因，帝视的本地卡录存储采用的方式是固定块循环覆盖写的方式。初次创建的时候，可以不预先占用空间，等逐步写入视频数据后逐步增加大小，一旦写满后，文件就不再删除，通过循环覆盖的方式淘汰旧的历史数据。
全时段录像 vs. 事件触发型
由于全时段录像需要大量的存储空间，带来比较高的成本。而实际情况下，视频画面在很多场景下并没有任何有用的信息，比如一个无人的室内场景，画面绝大部分时间都是静止的，但是录像还是一直在存储，浪费存储空间。虽然视频编码的VBR技术可以在画面静止是降低大部分的码率，为了保证一定的清晰度，小的码率还是很高。一个可行的办法就是当画面的内容有变化或者有感兴趣的事件发生时，才对视频流进行录像存储。典型的方式是加上移动侦测算法或人脸、人体检测算法，当有事件触发时，录像立即开启。这种方式即不会漏掉事件，也不会浪费存储空间。
磁盘空间管理
由于存储设备的容量是有限的，随着时间的推移，录像数据一定会装满整个存储区域。当存储空间耗尽后，需要有一定的方式对老的存储空间进行重复利用。另外，除了视频录像，还有一些额外的信息也需要存储，比如截图，业务数据和日志之类的。帝视服务的磁盘管理支持多样的模式来管理磁盘空间。
NVR 设备通常有许多个通道，每个通道会对应一路摄像头。每个通道的视频流会以某种格式存放在本地的磁盘上。通常来说，由于要保存较长时间的视频录像，需要较大的磁盘容量。目前市面主流的磁盘有机械盘、固态盘以及混合两种特性的混合盘。机械盘因为其容量大、价格低而成为 NVR 存储磁盘的首选。
机械磁盘的一个显著特性就是存在寻道时间，导致随机访问和顺序访问有这极大的性能差异。机械盘顺序读写的吞吐是优于随机读写的。虽然对于单路视频流录像而言，是满足顺序写入的，但是如果很多路(比如 16 路、32 路)同时写入还是会让磁头反复寻道。磁盘本身的 NCQ 技术虽然能缓解一部分，但是无法从根本上解决。
另外，NVR系统是一个 7x24 小时不间断的存储系统，随着时间的推移，终会耗尽所有的磁盘存储空间。典型的策略采用覆盖淘汰掉老的录像数据的方式，从而保持始终留存这个的录像数据。
磁盘一般会有 OS 提供的文件系统，录像数据则以一定的组织方式存在磁盘上，如果数据的组织方式不恰当，数据持续的淘汰会带来磁盘碎片，带来更多的寻道操作而影响性能，随着时间的推移，这个现象会越来越严重。
帝视 SDK 的存储系统是经过专门设计的数据组织方式，一方面保证很多路视频流写入时没有随机写入问题，另一方也保证数据的覆盖淘汰不会带来碎片问题影响性能。另外，在掉电后只有后写入的数据帧会受影响，其他的数据都不会收影响，确保数据的安全性。在NVR的场景，通常会挂载多块硬盘。为了提升整体的吞吐，需要把码流的写入分摊到多块磁盘上，并行写入。另外为了保证数据的安全性，也可以使用多个磁盘来做RAID。
卡录和NVR存储有着成本低廉的优势，但是无法应对盗抢和损坏问题。犯罪分子发现有摄像头时一般就会时间去破坏摄像头，导致无法通过监控录像来提供线索抓捕犯罪分子。普通的存储卡在多次插拔和一定时间的写入后，特别容易损坏。云端存储的方式则不受这些影响。另外，数据存储到云端，还可以进行有效的分析和处理，提取出更有效的信息，提升追溯问题时的效率。比如视频通过结构化分析处理后，就可以很方便的去搜索人、车和物品信息，并能快速、准确的定位到具体的时间和地点。同时，这些数据还能同其他业务数据形成数据湖，实现协同的价值。
把摄像头的实时视频数据上传到云端，有多种实现方式，对应帝视SDK的多种云存模式
流式传输 vs. 切片文件
摄像头的视频流本身是流式的，但是一般的云存储都是对象存储，并不是一个无始无终的流式文件，必须要把流式的视频流切割成一个个的文件。通常可以把流式的文件切割后存储成特定的容器格式，比如MP4和TS。因为MP4文件的写入通常涉及到索引的处理，需要seek到文件头进行索引位置的更新操作，并不适合边传输边写入。TS则比较方便，无需索引位置的更新，不过TS文件的overhead相对mp4来说要高一些。
设备端直接上传 vs. 云端切片上传
虽然终都需要对视频流进行切片，但是切片在设备上完成还是在服务器上完成，还是可以选择的。IPC设备上直接切片上传的好处是无需服务端处理，IPC设备侧完成所有的逻辑，缺点则是需要本地缓存一定量的数据，在切片没有缓存完成前，无法进行上传操作。如果切片在云端进行，那么就需要把码流推送到云端的服务器主机上（或者服务端主动去拉流），由这个服务器主机来对视频流进行切片和上传的云存储里。云端切片的方式能节省IPC设备端的缓存开销，IPC只需把流数据发送出来，就不用做任何其他事情了。
云端Meta信息存储
视频录像的切片存储到云存储后，还需要对meta信息进行管理。由于这些数据是一系列的时间序列，可以用时序数据库进行存储。对于直接播放的场景，服务端可以根据请求的时间段动态拼成m3u8文件返回给终端进行播放。如果需要导出，也可以转封装。
帝视服务提供云存的切片和上传功能，支持主流的对象存储服务(AWS 的 S3、阿里云的 OSS、智汇云的S3存储)。由于第三方存储服务都是上行免费的模式，帝视SDK 可以直接从设备端上传视频数据到云存服务。同时在弱网的时候，利用本地卡录来做缓存，不会因为短暂的网络中断而丢失云存数据。
对于基于摄像头类的应用场景，视频内容的实时观看与录像回溯是基础的功能。但是对于物联网场景，比如安防监控的视频播放、家用摄像头的视频播放与传统场景不太一样的地方就是能在公网上远程观看视频，并且利用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实现解码能力，也能充分利用系统的硬件加速，弥补这种模式带来的缺点。
RTC技术在互联网上已经得到了广泛的应用（短视频、直播、视频会议等等），已经彻底改变了我们的生活。在物联网领域，人们也有利用IOT设备进行实时音视频通话的需求。RTC技术目前已经算比较成熟了，但是嵌入式设备的计算力和内存资源就比较有限，无法简单把现有技术移植过来。比如音频的3A算法就比较消耗CPU计算，通常在嵌入式设备上的3A算法需要做特别的优化和裁剪。
帝视的RTC功能，支持1对1模式的对讲（全双工），也支持多对多模式的。对于一些需要与传统固话打通的场合，帝视还支持与PSTN固话网络的打通，可以通过嵌入式设备拨打传统的电话。
畸变矫正
所有光学相机镜头都存在畸变的问题，畸变属于成像的几何失真，它是由于焦平面上不同区域对影像的放大率不同而形成的画面扭曲变形现象，这种变形的程度从画面中心至画面边缘依次递增，主要在画面边缘反映得较明显。对于变焦镜头畸变的问题尤其严重，一般在广角端拍摄时，往往会使画面边缘向外凸起，称之为桶形畸变;用远摄端拍摄时，画面边缘经常会向内凹进，称之为枕形畸变。畸变会引起成像时的画面变形，大多数时候轻微的畸变并不会对画面质量有太大影响，但某些应用可能对畸变比较敏感，比如翻拍资料、拍摄建筑物等规则物体，都希望畸变不要太严重，否则会明显歪曲拍摄实物的几何特征。
为减小畸变，可以通过算法对畸变进行反向变换纠正。帝视监控 SDK播放端提供畸变矫正算法，支持多种畸变模式的校正，并且可以根据实际情况对畸变校正参数进行微调，从而达到理想的效果。
移动侦测
许多场景下监控画面是保持静止不动的(比如无人的场景)，但是摄像头还是保持视频编码和对视频流的存储。为了节省存储和传输成本，可以采用画面的移动侦测技术，只在有画面有变化时才开启录像。对于大部分场景，能极大的节省存储和传输成本。为了节省开销，一般需要嵌入式系统提供一路小分辨率的视频流来进行移动侦测算法。
声音变声
对于安防场景的摄像头或可视门铃，女主人有变男声来威慑坏人的需求。帝视的SDK提供了变声的算法，能把女声变成男声。如果客户有自己的算法，也可以通过帝视提供的前置处理接口，以插件注入的方式来做自定义的一些算法处理。
声波配网
对于嵌入式设备，对设备进行配网是一个比不可少的操作。通常配网方式有AP配网、声波配网、蓝牙配网、二维码配网等多种方式。对于声波配网，帝视SDK提供把配网信息打包到声音信号和从声音信号里恢复原始配网信息的功能。
对于海外售卖的摄像头设备，如果希望在亚马逊电商平台得到推荐，必须支持 WWA(Work With Alexa)，类似的谷歌也有Google Home 的带屏音箱。支持带屏音箱使得用户可以通过语音交互控制摄像头设备，让摄像头的监控内容显示在屏幕上。有些设备还能支持双向的视频通话，极大的丰富了应用场景。
与带屏音箱打通通常有两种实现方式: 一种实现在设备端，另一种实现在云端。实现在设备端需要硬件设备有更多的资源，这会增加对应的硬件成本。实现在云端则比较灵活，也方便后期扩展。关键的要素就是用户实际的使用量，如果用户频繁使用此项功能，带来较多的流量，那么放在设备端实现就比较合适；如果使用频度低，那么放在云端实现就是一个不错的选择。帝视当前已经实现了云端的支持。设备端在成本配置允许的情况下，也可以通过集成对应的 SDK 来实现对带屏音箱的支持。
GB28181的全称是“公共安全视频监控联网系统信息传输、交换、控制技术要求”，目前广泛应用于政府项目中。GB28181规定了城市监控报警联网系统中信息传输、交换、控制的互联结构、 通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、传输流程和协议接口等技术要求，解决了不同的硬件厂商、集成商以及各种应用系统间监控数据的接入、交换与控制问题。凡是符合国标标准的摄像头或NVR设备可以无缝的接入到国标管理平台。如果设备想要支持GB28181标准，只需要集成帝视的设备端SDK。
ONVIF（开放式网络视频接口论坛）是一个全球性的开放式行业论坛，其目标是促进开发和使用基于物理IP的安全产品接口的全球开放标准。ONVIF创建了一个视频监控和其他物理安全领域的IP产品如何进行相互通信的标准，旨在实现跨生产商的网络物理安全产品之间的互操作性。帝视对ONVIF的支持类似GB28181，这里不再赘述。
6. 端到端的数据安全
在大数据时代，数据的安全性不言而喻。传统的视频监控只是运行在局域网或专网环境，面临的安全威胁并没有那么大。帝视提供的服务则是面向互联网的，在数据安全方面需要更加严格的保护。对数据的保护离不开加密技术，目前大部分应用都采用信道加密技术（比如TLS、HTTPS）来保障数据不被嗅探和篡改。通常来说，对一个庞大的系统，信道加密技术只应用于一个节点与另外一个节点间的通信，数据在节点内部，还是以明文的方式存在与被处理的。在有“内鬼”的情况下，还是无法保障数据的安全。除了信道加密，帝视服务还采用了“端到端”的信源加密方式。秘钥由业务方来管理，帝视服务并不接触和存储数据加密秘钥，从根本上解决了数据安全问题。
360智汇云物联网视频解决方案-帝视平台，从用户的痛点出发，结合360多年的技术积累，打造了物联网视频应用的底层基础设施。通过使用帝视的服务，客户从技术密集与重资产的视频服务中解放出来，可以更好的专注与自己的业务。帝视的增值服务，也让硬件厂商有了更多的获利空间。
视频已经引领了消费互联网的一次信息革命，同样在不远的将来，视频也会带来物联网领域的信息革命。物联网使得信息从虚拟空间延伸到物理空间，摄像机代替了人类的眼睛与耳朵，AI技术代替了人类的大脑，让机器以人类的感知和理解方式去看这个世界，与人类交互，智能就在我们身边！
原文：
https://zyun.360.cn/blog/?p=799
