智慧城市已被谈及多年，“监控视频+AI”也成为众多公司研究的方向。
但现阶段，通过监控摄像头让城市变得更智智慧，不仅仅是单一的视频检索和计算机视觉问题，而是在面临海量信息和突发事件时，能否能迅速做出反应、能否降低计算量、能否有效识别和检索等一系列庞大的系统工程。
现有视频监控体系的弊病，使得很多复杂任务无法完成，即便是人工智能大规模渗入后，需求方也往往为了一些特殊目的才加特定的智能摄像头和处理系统。
有些专用摄像头只是用来识别车牌号，有些摄像头只用来识别人脸，这种打补丁式的方法实际会带来很多问题。
针对这些问题，中国工程程院院士、北京大学教授高文给出了他的指导意见和解决方案，以下是高文院士讲话内容。
（本文由高文院士亲自审改）
杭州是国内智慧城市做得比较好的城市，有一些区域也在试验“城市大脑”系统。
杭州城市大脑的过去与现状
我们先来看下杭州城市道路的数据：
目前杭州大概有600多条线路、5万条道路、8万多个路口。这些路线上有着200万辆车，其中包括9000辆公交车，每天的乘客流量高达390万。
在如此大规模且极其复杂的系统里，要做好规划和管理实际上非常艰难。
这是杭州智慧城市使用城市大脑系统所做的整体规划：
过去城市智能交通的规划方式，根据每个路口的交通状况做分析，然后给出模型，这些环节需要规划每个信号灯红黄绿应该各维持多长时间。但这种方式只能做到局部区域的优化，无法达到整个城市的全局优化。
那么如何来控制红绿灯的时间？
下图是他们通过云计算把城市的信号灯规划重新调整以后得到的结果，大家可以看到城市交通状态分成低保和、中报和、准饱和三个阶段：
1、最好的是低饱和，路上车不多
2、其次是中饱和，路上车辆数量正好
3、最差是准饱和，车几乎无法行驶
之前汽车在杭州这条线路的行驶速度分别是37公里、30公里和22公里，经过全局优化后，这条线路的平均速度为43公里、35公里和26公里，整体提速17%。
在没有对道路进行调整的情况下，只对信号灯控制做了优化就能提速17%，这非常了不起。
具体是如何做得优化？
杭州市通过城市交通管理云进行规划，除了规划信号灯本身外，还架设了摄像头。
摄像头每时每刻都在拍路面，并计算车的占有率（即每百平方米路面中车的数量），基于此来判断每条道路的饱和程度，然后对信号灯进行优化。
把一个月全天24小时的数据输进去后，重新进行计算。但这些数据往往不一样，因此需要有一个数据交换平台。
数据交换平台上是算法平台，再上层才是应用和服务平台。
上述提到的内容和PPT便是整体交通的优化，当然，这里面不少也与视频有关，涉及到各种各样的模块。如果信号进来，它在摄像头上做编码，传到云端做解码，解码后再去提取特征、做分析等，这是常规的流程。
但这样的系统怎么样？是不是一个理想智慧城市系统？我的答案：不是。
怎样才是理想型的智慧城市系统？
刚才谈到的那种方式，根据以往的数据来做调度规划，总体不错，但对突发事件无法及时做出判断。
最理想的方式不仅可以通过以往的数据统计进行决策、进行查询，而且也可对实时的数据进行处理、分析。
世界各地的紧急事件发生时，系统整体的响应速度实际都比较差。
为什么？主要因为现在整个视频监控体系本身造成。
视频监控体系的三个问题
现在的视频监控系统，从一开始就面临数据量太大、存储量太大，查找数据不易等一系列挑战，这些挑战可以归纳成三个问题：难存储、难检索、难识别。
1、存储成本高
存储成本高的主要原因就是数据量太大，而且要求存的越久存储成本就越高。
为了加快速度，减低成本，通常做法是往狠里压缩，同时缩短视频存储周期：缩短到两周，之后数据逐渐把前面数据慢慢覆盖掉。
2、检索困难
之所以不能进行实时反馈，是因为目前的监控体系都是为存储而设计。
把数据存到库里，是监控体系的第一要务。什么时候你要用，常规的做法就是把数据提出来，解开，然后再做后面的处理。这就导致存储时已经丢掉了很多东西，在此基础上再去做识别效果会比较差。
3、对象再标识难
尽管视频录下来了，但A摄像头录的信息你找到了，不见得在B摄像头上能对得上，这也是一个非常难的挑战。
针对这些挑战，我们必须想办法找一个更好的方案来解决现有智慧城市系统面临的问题。
这时候，我们不仅要把东西存储起来，而且能够实时对任何想识别、想搜索的信息进行实时操作。
现在的系统主要是用摄像头把视频抓进来后压缩，传出去，然后存起来。
在很多设有卡口的道路，专门安装了卡口服务器，以此来识别车牌号。有些道路还专门安装高清跟踪摄像头，用于踪人和车。
上述情况往往是为了一些特殊目的才加的摄像头和处理系统。
这种打补丁式的方法实际会导致很多问题。
简单来说就是你有A需求，便装一个系统，你有B需求，于是再装另外一个系统，然后把所有任务抓取的视频都推到云端，这就是现有系统通常采用的设计模式。
我把它叫做“1-1模式”。
不断“打补丁”的监控系统
“1-1模式”存在很多问题，其中包括数据之间的同步，将来需要统一的数据很多，如果在系统里想做交叉检索，时间差维度上，对接起来会比较困难。
除此之外，因为时间点的不同，对应要手工加很多东西，加工结果是否是系统能规范化、标准化的也非常难说，而且这样的系统很容易造成一些问题。
如果只是存储问题，但没及时分析，很容易导致辨识时间较长，因为你把编码通过网络送到存储端，如果要用的话，还要解码，要做特征提取、特征分析识别等，一系列流程下来，实际上很耗费时间。
而且一旦存在硬盘里，还存在部分信息读取不到的可能，这就会导致更大的问题。
“1-1模式”存在的另一个不足就是准确性比较低，这是所有问题里最严重的。
当视频做完压缩后再去识别，它的性能比不压缩要差，也有损失。
我举几个例子：
从上图可以看到，压缩幅度的不同，使得从左到右图像清晰度越来越差。当给它一个量化参数时，观察QP27、QP32、QP38，数字越大，实际上压得越狠，信息出错的概率也越大。
那么QP值压缩参数选多少比较合适？
不同的标准多多少少是有差别的，我们做了一个测试（参考上图）。
如果采用H.265/AVS2（关闭背景模式）的标准，把AVS2模式打开后，码率（Bitrate）值会很高。把模式关掉时，我们对50P的高清视频进行测试，通过QP参数值25、32、38、40、51、63来设定，设定以后，对应视频流的码率红色区域从13MB到5MB、2.4MB，下方蓝色区域为1.3MB、0.7MB、0.3MB。
高清视频一路无需1MB，700K就已足够。700k和300k差不多也就需要QP50到60之间的压缩能力。
这个能力压缩到这一值上是很糟糕的情况，后来我们做大量的分析实验发现，发现QP取值超过38，后期去检查人、车时，时间利率就会急剧下降。（如下图）
QP值38是一个拐点，此拐点看上去有点不可思议。
对于50P的高清视频分辨率，为了保证后面的识别最低的码率为2.4MB，低于这个水平去做识别，质量会比较差。
这件事告诉我们，追求高压缩率和追求高识别率属于鱼和熊掌不能兼得。压缩率高了，识别率就随之下降，而识别率高的前提是减下压缩率。
除了前面提到的两个问题外，还存在一大难题是面向存储的利用率比较低。
每次查找得先解码，然后再一个个的找，这对服务器的计算能力要求非常高。因此要想在存储视频研究中心或者分中心里进行大规模检索查找，实时性往往无法满足。
大部分情况下，整个数据和算法的利用率极低，如果数据能实时进行检索和分析，显然两者的利用率会更高。
利用率低如何解决？
…………
接下来还有3000多字的方案详情和31张信息量巨大的PPT，高文院士详细介绍了数字视网膜解决方案，包括：
1、数字视网膜三大核心技术：
基于背景模型的场景视频编码
视频特征的紧凑表达
视频编码与特征编码的联合优化
2、数字视网膜硬件实现、系统部署、实时/离线实施方案
3、云端系统三大构建模式：
直接基于特征码流
在特征码流上深度分析
前端简单识别+云端大数据搜索
4、数字视网膜网络标准
