作者认为一直传输视频很浪费带宽，实际上只有很小一部分视频会最终被query。而且摄像头的存储成本很低，便宜的摄像头也能存一个月的视频。作者提出zero-streaming，摄像机将视频存在本地，对查询做出响应。查询分成多轮，每轮产生及时有效但不一定准确的中间结果，多轮逐步将结果的准确率提高。
文章的核心idea有两个：
文章认为稀疏但非常准确的知识比全面但没那么准确的知识更重要，所以文章的设计是每隔一段时间（例如30s）给一个帧（叫做landmarks）做高精度的目标检测，结果可以用于优化之后的查询。摄像头的算力一般能够支持0.1~0.5 FPS的高精度目标检测。 通过收集到的landmarks可以获得一些信息，例如目标大致会出现在什么位置。文章提到会将这些信息用在摄像头端的filter上，但我觉得这样可能会过于激进，以至于遗漏一些unusual cases。
在摄像头端，从低到高地用不同精度的模型去query视频，保证容易检测的结果先检测出来。 作者认为可用带宽和模型精度之间有interplay，因为模型检测不出来时要通过网络传输到云端。低精度模型可以更快找到容易检测的结果，但更慢找到所有结果。模型推理速度要匹配传输的速度，所以低带宽应该搭配高精度模型来减少帧传输，高带宽应该搭配低精度模型来更快得到初步结果。
还有摄像头端模型怎么选择处理的帧以及云端怎么选择更新摄像头端模型的问题。前一个模型的结果会用于当前模型决定处理帧的顺序，但也会兼顾没有被前一个模型处理的帧（赋一个0.5 of 1的顺序分数）。如果上传的帧不够有用了（例如包含object的帧数不够多），云端就更新摄像头端模型。摄像头端模型还需要云端根据上传的帧进行训练和评估。
整体的workflow如下：
感觉到这里两个idea有点矛盾，第一个idea说摄像头算力有限，第二个idea又开始在摄像头端运行高精度模型。而且低精度模型的结果真的可信吗？false negative和false positive真的可以控制吗？从设计上来说也有局限性，例如对短视频来说流程非常繁琐，landmarks可能信息量不够等。
而且实验用的数据集居然是720P at 1FPS lasting 48 hours，根本不能算是video，可以说实验没有做到文章设想的东西，对比之下junchen jiang组的文章质量要高多了。
主题：AccMPEG: Optimizing Video Encoding for Accurate Video Analytics
报告人：李一宏
简介：文章探讨如何实时压缩视频并将其从边缘端流式传输到远程服务器，同时保留足够的信息以允许服务器端的视频分析神经网络进行推理。文章提出的具体做法是在边缘端部署一个可以预测视频帧中每个宏块的编码质量的神经网络，边缘端根据预测结果实时调整视频的编码质量。文章为这个边缘端神经网络提出了一个叫accuracy gradient的学习目标，它可以反映宏块的编码质量对服务器端视频分析神经网络准确性的影响有多大。
这篇文章的idea比较简单，就是在边缘端部署一个可以预测需要传输的视频的一个帧的encoding quality的模型，边缘端根据模型预测结果实时调整视频的encoding quality，用一个帧的encoding quality预测结果应用到一个chunk上。
video analytics的过程，需要保证High accuracy，Low delay和Low camera cost。
简单算一下大小，假设720P的视频，12807203*30/1024/1024=79.1015625。
有些论文还会将服务器的推理结果返回给client，这篇论文就没有考虑这种情况。
Limitations of previous work edge端的frame filter，如果视频内容不是静止的，或者视频分析任务要求分析每一帧的话就不合适
edge端的object-based encoding，用一些heuristic或者object detector去区分背景和物体的编码质量，文章认为一是heuristic不够准确，二是精准的object detector需要更多边缘计算资源。我对目前的高精度object detector在边缘端部署不是很了解，如果可以做到的话在边缘端决定编码质量是要更好的。
server端的region proposals回传给edge端用来指导encoding，这分为两种情况，server端能不能基于最新的帧给出region proposals，如果能看到帧，会有延迟，虽然也有提出一些机制可以去应对这种情况，比如两周前其他同学分享的mobicom19的文章，它就是利用编码技术里面的Motion vectors去预测bounding box会移动的方向。
模型不同部分边云分开部署，对中间结果（feature maps）进行压缩。它在小任务上可能表现得好，但在复杂的vision tasks这其实并不比直接传视频好，比如有些大模型的一个帧的feature maps的浮点数可能比它原始的RGB的值都要多。
Accuracy Gradient的定义。B是一个块，i是块里面的一个像素点，H和L是高画质图像和低画质图像，D(x)是video analytics的推理模型，输入图像输出推理结果，Acc函数是计算两个输出推理结果之间的相似度。
文章在附录里面给了这个定义背后的数学含义，是从最大化Acc出发，通过拉格朗日中值定理转成这个样子，但我觉得它的推导很牵强，意义不是很大，就不展开讲了。我在这里讲讲我的理解，后一项H和L的L1距离，比如说对一片蓝天的压缩，不会怎么影响RGB，低画质和高画质的RGB可能是接近的，所以这个值越小，提升画质就越没必要；前一项是一个梯度，把Acc函数的定义域是L到H，那如果全程的梯度都很大，说明从L到H对准确率的提升很明显，前一项越大说明对推理结果影响越大。但是文章用的是在L这个位置的梯度，就是说我只通过L点的梯度去估计我全程的梯度，这是没有什么理论保证的，因为L到H的Acc函数的形态是未知的，它甚至都不一定单调。
如果用这样的指标去指导编码会有什么好处呢，和object-based encoding比较，在方法上的优势：
AccMPEG的流程，quality selector由服务器训练，部署在边缘，它和普通的object detector相比更加轻量，因为它只输出16X16个Marcoblock的Accuracy Gradient，它的计算量也是很小的，例如和语义分割相比，因为视频编码一般分成16X16的块，它相当于一个16X16的二分类语义分割。有点像神经网络分析可解释性的saliency maps，不过saliency maps是反映像素值对结果的影响，accuracy gradient反映的是一个块的编码质量对结果的影响。
Accuracy Gradient超过一定的阈值，就会将它和它周围的k个块提升到高的quality。文章里找的k的值是5。
编码以一个chunk为单位，一个chunk里面10个帧的编码都按前面的quality assignment来编码。
文章通过QP(Quantization Parameter) 控制每帧视频中每一个宏块的压缩量。实际上，QP 反映了空间细节压缩情况。QP 越大，细节信息丢失的越多，码率也会随之降低，但图像失真也会越严重。也就是说，QP 和码率成反比。
在 H.264/H.265 的视频编解码里面中，QP 的取值范围为 [0,51]。文章是只选其中两个值，来作为低画质和高画质。...
hotcloud的短文，用超分重建从client传来的低分辨率视频，超分模型部分的idea基本和infocom21，然后扩刊TCC22的那篇一样，就是加一个和视频分析有关的loss。
两个重要设计：
用神经网络的方法去预测一个帧和上一个key frame之间的差别，去预测segmentation maps的偏移程度，决定该帧的重要性； 在一些金字塔输入结构的网络中，可以省掉下采样的操作，因为传的就是低分辨率视频。 即使超分好用，还是可能出现性能骤降的情况，还是需要一个knob policy去调节清晰度。
文章还提出一些Discussion：
神经网络插帧，进一步降低带宽需求（不太现实，相当于要预测物体移动）； 怎么为基于神经网络的系统兜底； video analytics 关注的视频质量指标到底是什么； 用视频数据线上学习。
很多video analytics都是client端决定传输质量，为什么需要server driven？一个原因是client端不好估计视频传输质量对推理效果的影响，另一个原因是推理效果在server端可以很直观地给出，这对于视频的补充需求是一个context。另外有些工作也是server driven，但这些早期工作是直接调整视频的质量，但实际上不需要再传视频，只需要提高画质的那部分region就好了。这个分析我是比较认可的，会比其他基于超分或者client端heuristics的工作的上限和稳定性都更好。文章设置了很多人工参数和阈值去决定哪些是需要重传高画质的regions。
但这个工作因为需要多轮的resend，delay会超过1秒，如果可以实现0 resend可以降低很多延迟，而且准确率保持一致的话会是一个不错的创新，低延时的server端推理在自动驾驶等领域比较有价值。自然的想法是可不可以在edge端把ROI全部抠出来，然后只传ROI？是不行的，region proposals是由feature maps产生的，而feature maps有需要很多层卷积，在client端做不了。原始视频副本最终肯定会用某种方式保存回server，无论是传输还是人工回收，所以更应该考虑的是对大规模部署camera的信息分析的实时性，和适用的query种类的多样性。另外一篇几乎同时期的文章Video Analytics with Zero-streaming Cameras有这样的思想，之后会看一下。另外这篇文章的作者今年又发了一篇MLsys，从视频编码的角度入手：AccMPEG: Optimizing Video Encoding for Accurate Video Analytics。
hotcloud的短文，现在的视频流传输的方案对服务器端的视频分析模型是无感知的，视频分析的视频流传输方案的目的是在带宽限制下，适当用一些降分辨率和抽帧的方法，达到最高的推理准确率。旧的视频流传输方案大多面对的是人的观看体验，而视频分析要求推理准确率高。
文章提出，因为低质量的视频中能知道一些大概的信息，所以可以先发低质量视频，服务器再决定哪里需要补充。用一个叫Superposition Coding的叠加编码，先发一些基本的低质量视频，再按需要补充帧和高分辨率，模型需要分辨出什么region看得不够清楚，需要分辨出两个帧之间是否有遗漏的信息，可以把这个过程看成主动学习，通过尽可能少的帧达到一定的准确率，设定每帧预测的deadline，提前退出。
论文给的idea，client端和server端更好的集成，为特定推理任务定制策略。
datapath:
对于相对粗粒度的任务调度问题，用神经网络的方法对性能还没有太大影响，但如果是内核级别的例如进程调度，拥塞控制等，神经网络方法的overhead就是非常需要减少的。
现有的方法，要么程序全部放在用户态，训练和编程比较方便，但是内核态需要调用用户态的程序，造成状态切换会导致很大开销，特别是在例如拥塞控制多个并发数据流的情况；要么程序全部放在内核态，首先内核态基本支持不了NN的训练，因为内核态不能调用用户态的库，要是把NN量化+优化之后放进内核纯做推理，也不能适应变化的数据流环境。虽然不知道数据流特征的更新频率大不大，但我觉得不能适应环境应该是训练不够充分，不是个性化场景的话retraining感觉不用很频繁，例如Nvidia的DLSS就是纯推理的部署，而且从2.0开始就是generalized的，只需要时不时根据新出的游戏更新优化一下。
LiteFlow的workflow是部署一个只作推理的模型snapshot在内核态，然后收集snapshot的输入输出，在用户态batch-wise训练，通过比较用户态模型和内核态snapshot的性能，决定是不是要更新snapshot。
对用户态模型转内核态代码，用的是量化+代码生成的方法，对于一些内核态没办法用的算子（例如tanh）就用类似泰勒级数的方法去近似，所以还要针对不同的函数做近似，非常麻烦。
snapshot更新不是原地的，而是先copy后切换，不需要中断服务。active-standby-switch