Server-Driven Video Streaming for Deep Learning Inference
Howard Yin 2021-03-27 14:44:02 论文笔记目标跟踪云计算
@inproceedings{ServerDrivenVideoStreamingDeep2020,
title = {Server-{{Driven Video Streaming}} for {{Deep Learning Inference}}},
booktitle = {Proceedings of the {{Annual}} Conference of the {{ACM Special Interest Group}} on {{Data Communication}} on the Applications, Technologies, Architectures, and Protocols for Computer Communication},
author = {Du, Kuntai and Pervaiz, Ahsan and Yuan, Xin and Chowdhery, Aakanksha and Zhang, Qizheng and Hoffmann, Henry and Jiang, Junchen},
date = {2020-07-30},
pages = {557--570},
publisher = {{ACM}},
location = {{Virtual Event USA}},
doi = {10.1145/3387514.3405887},
url = {https://dl.acm.org/doi/10.1145/3387514.3405887},
urldate = {2021-01-24},
eventtitle = {{{SIGCOMM}} '20: {{Annual}} Conference of the {{ACM Special Interest Group}} on {{Data Communication}} on the Applications, Technologies, Architectures, and Protocols for Computer Communication},
isbn = {978-1-4503-7955-7},
langid = {english}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 概述
# 应用场景
- 摄像头向服务器传输视频
- 服务器DNN执行目标检测或语义分割
- 网速不足以支持高清视频
# 传统方法
- 根据网速情况调整传输视频的清晰度
- 摄像头先判断图像的重点区域，只传输这些重点区域
# 本文方法
- 摄像头先传低清帧
- 服务器端的DNN反馈重点区域给摄像头
- 摄像头再把重点区域发给服务器端进一步识别
# Introduction
# 视频流领域的关键设计问题：在何处进行优化决策
# Source-Driven：在视频流源端进行优化决策
- 常见于视频播放应用：Youtube、Netflix等
- 常见的框架：DASH(Dynamic Adaptive Streaming over HTTP)
Source-Driven适用的前提：
- application-level quality可以被Source端知晓
- Destination端的user experience无法实时测量
# 实时目标识别领域Source-Driven为什么不好？
在实时目标识别领域，Source-Driven意味着摄像头需要承担优化任务：决定视频流质量、决定传帧的哪些部分等
Source-Driven前提不满足：
- Source端（摄像头）无法估计application-level quality（服务器上的识别准确率）
- Destination端（服务器）的user experience（DNN输出的置信度）可以实时测量
# 本文如何解决这个问题：DDS(DNN-Driven Streaming)
根据服务端的DNN输出进行优化决策
- 摄像头先传低清帧
- 服务器端的DNN反馈低清晰度上的识别结果给摄像头
- 摄像头根据反馈的识别结果把重点区域发给服务器端进一步识别
# 挑战：DNN反馈哪些识别结果
本文主要关注于三个领域：
- 目标检测
- 语义分割
- 面部识别
观察到的现象：低质图虽然不能给推断带来高正确率，但可以很好地找出疑似目标的位置
# 现有的类似解决方案
- 由摄像头判断哪些位置重要
- RPN(region-proposal networks)：一种专用于判断图像重点区域位置的网络
- 缺陷：RPN只在目标较大时效果好；不适用于语义分割
- 注意力机制
- 与本文非常类似，都是关注于重点区域
# Motivation
# 强终端vs弱终端+强服务器：省钱！
弱终端+强服务器：NVIDIA Tesla T4 GPU (with a throughput of running ResNet50 at 5,700FPS) costs $23 × 60(cameras)+$2000(GPU)= $3.4K
强终端：60 NVIDIA Jetson TX2 cameras (each running ResNet50 at 89FPS) costs about $400×60 = $24K
# 性能参数
- Accuracy：本文的识别结果和DNN直接处理高清全图的结果之间的相似性
- Bandwidth usage：数据传输量/时间
- Average response delay (freshness)：处理时间/识别目标数量（或语义分割中的像素数量）
# 可以进行设计的部分
- Leveraging camera-side compute power：使用相机提前去除无用部分
- 缺点：由于性能限制，精度很低
- Model distillation：裁剪模型
- 缺点：This approach is efficient only in training smaller DNNs that work well on less expensive hardware.（没懂，什么意思）
- Video codec optimization：使用基于内容的编码方式
- Temporal configuration adaptation：基于视频内容调整帧码率
- 一帧只能一种编码，无法适应帧内部的内容分布不均
- Spatial quality adaptation：根据帧内部的内容分布调整不同区域的码率
# 潜在的优化空间
- 给人看的视频流要求每个地方都清晰，要有背景，还要流畅回放，给机器看的视频不需要这些
- 一个视频里，有50%~80%的视频帧中目标像素少于20%
因此，根据帧内内容分布裁剪背景是一个很好的选择。
# 现有方法的局限性
- 相机侧进行切分：算力不足以支持精确的算法
- 服务侧全部包办：消耗大量带宽，一点点的性能提升就要多耗费巨大的带宽资源
# 系统设计
# Server-Driven和传统Source-Driven对比👇
# 哪些区域需要高清？👇
- 目标检测应用（结果为很多框，每个框对每个标签都有一个分数）
- 哪些区域不用高清feedback region：分数很高的框、很大的框
- 哪些区域需要高清feedback region：除上述框之外的所有识别出目标的框都要高清
- 语义分割应用（结果为每个像素对每个标签都有一个分数）
- 哪些区域需要高清feedback region：分数最高的标签和分数第二高的标签分数差小的像素
- 用框框住尽可能多的高分数差像素
- 哪些区域需要高清feedback region：分数最高的标签和分数第二高的标签分数差小的像素
# 如何适应变化的带宽？
- 依据：上一帧传输时的所用带宽、当前待传输帧的可用带宽（通过卡尔曼滤波估计）
- 调节：高清视频流清晰度、低清视频流清晰度
# 如何传帧局部？
- 将feedback region之外的区域置0，让视频编码器去压缩