Video Analytics with Zero-streaming Cameras

TL;DR

This paper introduces DIVA, a system for efficient querying of large videos stored locally on low-cost cameras, using novel techniques to optimize resource use and query speed, achieving over 100x real-time performance.

Contribution

DIVA is the first system enabling efficient querying of large videos on low-cost remote cameras through innovative sparse landmark frames and multi-pass query processing.

Findings

DIVA achieves over 100x real-time video query performance.

It outperforms alternative designs on diverse queries over 720 hours of video.

DIVA effectively balances resource use and query accuracy during execution.

Abstract

Low-cost cameras enable powerful analytics. An unexploited opportunity is that most captured videos remain "cold" without being queried. For efficiency, we advocate for these cameras to be zero streaming: capturing videos to local storage and communicating with the cloud only when analytics is requested. How to query zero-streaming cameras efficiently? Our response is a camera/cloud runtime system called DIVA. It addresses two key challenges: to best use limited camera resource during video capture; to rapidly explore massive videos during query execution. DIVA contributes two unconventional techniques. (1) When capturing videos, a camera builds sparse yet accurate landmark frames, from which it learns reliable knowledge for accelerating future queries. (2) When executing a query, a camera processes frames in multiple passes with increasingly more expensive operators. As such, DIVA presents and keeps refining inexact query results throughout the query's execution. On diverse queries over 15 videos lasting 720 hours in total, DIVA runs at more than 100x video realtime and outperforms competitive alternative designs. To our knowledge, DIVA is the first system for querying large videos stored on low-cost remote cameras.

Tables

Table 1. Table 1: Cheap μ 𝜇 \mu SD cards on cameras retain long videos for humans to review  [ 4 ] or for machines to analyze  [ 51 ] .

Size	Yr.2017	Yr.2020	720p@30FPS	720p@1FPS
128GB	$45	$17	$\sim$11 days	$\sim$3 weeks
256GB	$150	$28	$\sim$3 weeks	$\sim$ 6 weeks

Table 2. (a) Hardware platforms

	Cam:Landmarks	Cam:Query	Cloud:Query
ClondOnly	–	Only upload frames
OptOp	Yv3 every 30 secs	Run one optimal op	Yv3 on all
PreIndexAll	YTiny every sec	Parse YTiny result	uploaded frames
DIVA	Yv3 every 30 secs	Multi passes & ops

Table 3. (b) DIVA and the baselines . The table summarizes their executions for capture and query. NNs: Yv3 – YOLOv3, high accuracy (mAP=57.9); YTiny – YOLOv3-tiny, low accuracy (mAP=33.1).

	Cam:Landmarks	Cam:Query	Cloud:Query
ClondOnly	–	Only upload frames
OptOp	Yv3 every 30 secs	Run one optimal op	Yv3 on all
PreIndexAll	YTiny every sec	Parse YTiny result	uploaded frames
DIVA	Yv3 every 30 secs	Multi passes & ops

Table 4. Table 4 : 15 videos used for test . Each video: 720P at 1FPS lasting 48 hours. Column 1: video type. T – traffic; O/I – outdoor/indoor surveillance; W – wildlife.

	Name	Object	Description
T	JacksonH [25]	car	A busy intersection in Jackson Hole, WY
	JacksonT [26]	car	A night street in Jackson Hole, WY
	Banff [20]	bus	A cross-road in Banff, Alberta, Canada
	Mierlo [29]	truck	A rail crossing in Netherlands
	Miami [28]	car	A cross-road in Miami Beach, FL
	Ashland [19]	train	A level crossing in Ashland, VA
	Shibuya [31]	bus	An intersection in Shibuya (渋谷 ), Japan
O	Chaweng [22]	bicycle	Absolut Ice Bar (outside) in Thailand
	Lausanne [27]	car	A pedestrian plaza in Lausanne, Switzerland
	Venice [32]	person	A waterfront walkway in Venice, Italy
	Oxford [30]	bus	A street beside Oxford Martin school, UK
	Whitebay [33]	person	A beach in Virgin Islands
I	CoralReef [23]	person	An aquarium video from CA
	BoatHouse [21]	person	A retail store from Jackson Hole, WY
W	Eagle [24]	eagle	A tree with an eagle nest in FL

Full text

Video Analytics with Zero-streaming Cameras

Mengwei Xu

Peking University

Tiantu Xu

Yunxin Liu

Institute for AI Industry Research (AIR), Tsinghua University

Felix Xiaozhu Lin

University of Virginia

††*Mengwei Xu and Tiantu Xu contributed equally to the paper.††*Work done during Mengwei Xu’s visit to Purdue University.

Abstract

Low-cost cameras enable powerful analytics. An unexploited opportunity is that most captured videos remain “cold” without being queried. For efficiency, we advocate for these cameras to be zero streaming: capturing videos to local storage and communicating with the cloud only when analytics is requested.

How to query zero-streaming cameras efficiently? Our response is a camera/cloud runtime system called DIVA. It addresses two key challenges: to best use limited camera resource during video capture; to rapidly explore massive videos during query execution. DIVA contributes two unconventional techniques. (1) When capturing videos, a camera builds sparse yet accurate landmark frames, from which it learns reliable knowledge for accelerating future queries. (2) When executing a query, a camera processes frames in multiple passes with increasingly more expensive operators. As such, DIVA presents and keeps refining inexact query results throughout the query’s execution. On diverse queries over 15 videos lasting 720 hours in total, DIVA runs at more than 100$\times$ video realtime and outperforms competitive alternative designs. To our knowledge, DIVA is the first system for querying large videos stored on low-cost remote cameras.

1 Introduction

Cameras are pervasive: a survey of 61 organizations shows that from 2015 to 2018 their average number of cameras has increased by almost 70%, from 2,900 to 4,900 [6]. Insights of videos can be extracted by queries such as “get the daily peak pedestrian count in the past week” [67, 101, 82, 36]. Four recent trends motivate our work.

(1) Low-cost, wireless cameras grow fast   As key complements to high-end cameras, low-cost cameras (<$40) are increasingly pervasive [17, 18, 34]. These cameras often have limited compute resources yet spacious storage. Being wireless, these cameras are meant to be installed by individuals or small businesses with ease just as other wireless sensors.

(2) Most videos are cold   Users deploy cameras to knowingly capture excessive videos, expecting that most videos will never be queried [72]. This is because interesting events are often unforeseeable, e.g., car accidents; the need for examining such events emerges well after the fact. $\S$2.1 presents a 6-month study of real-world camera deployment, where only <0.005% of captured videos are eventually queried.

(3) Transmitting cold videos wastes wireless bandwidth   Cold videos should not compete with human users for network bandwidth. If streaming video in real-time, a single camera generates traffic at 0.2 MB/s–0.4 MB/s (720P@1–30 FPS); with multiple cameras on one network, their always-on streams easily consume most, if not all, bandwidth of consumer WiFi, which is 0.2 MB/s–3 MB/s (median: 0.99) in a recent global survey [9] and less than 1.5 MB/s in an academic study [47]. A dedicated network for cameras is expensive, as the network monetary cost will exceed the camera cost in several months [14].

(4) Camera storage can retain videos long enough   A cheap camera can already store videos for weeks or months. Such retention periods already satisfy many video scenarios [2, 10]. In fact, legal regulations often prevent retention longer than a few months, mandating video deletion for privacy [7, 1]. Existing measures can assure data security of on-camera videos. $\S$2.3 will provide evidence in detail.

Zero streaming & its use cases

How to analyze cold videos produced by numerous low-cost cameras? We advocate for a system model dubbed “zero streaming”. (1) Cameras continuously capture videos to their local storage without uploading any. (2) Only in response to a retrospective query, the cloud reaches out to the queried camera and coordinates with it to process the queried video. (3) While the video is being processed, the system presents users with inexact yet useful results; it continuously refines the results until query completion [50]. In this way, a user may explore videos through interactive queries, e.g., aborting an ongoing query based on inexact results and issuing a new query with revised parameters [46, 45]. Zero streaming has rich use cases, for example:

• •

To trace the cause of recent frequent congestion on a highway, a city planner queries cameras on nearby local roads, requesting car counts seen on these local roads.

• •

To understand how recent visitors impact bobcat activities, a ranger queries all the park’s cameras, requesting time ranges where the cameras capture bobcats.

Advantages

Zero streaming suits resource-frugal cameras in large deployment. When capturing videos, cameras require no network or external compute resources. Only to process a query, the cameras require networks such as long-range wireless [35] and cloud resources such as GPU. Zero streaming adds a new point to the design space of video analytics shown in Figure 1. It facilitates retrospective, exploratory analytics, a key complement to real-time event detection and low-delay video retrieval [65, 99, 51, 55]. The latter demands higher compute or network resources per camera and hence suits fewer cameras around hot locations such as building entrances.

DIVA

To support querying zero-streaming cameras, we present a camera/cloud runtime called DIVA. As shown in Figure 2, a camera captures video to local storage; it deletes videos after their maximum retention period. In response to a query, the camera works in conjunction with the cloud: the camera runs operators, implemented as lightweight neural nets (NNs), to rank or filter frames; the cloud runs full-fledged object detection to validate results uploaded from the camera. DIVA thus does not sacrifice query accuracy, ensuring it as high as that of object detection by the cloud.

The major challenges to DIVA are two. (1) During video capture: how should cameras best use limited resources for future queries? (2) To execute a query: how should the cloud and the camera orchestrate to deliver useful results rapidly? Existing techniques are inadequate. Recent systems pre-process (“index”) video frames as capturing them [51] and answer queries based on indexes only. Yet, as we will show in $\S$8, low-cost cameras can hardly build quality indexes in real-time. Many systems process video frames in a streaming fashion [100, 97, 40, 42, 92], which however miss key opportunities in retrospective queries.

To this end, DIVA has two unconventional designs.

• •

During video capture: building sparse but sure landmarks to distill long-term knowledge (Figure 2(a)) To optimize future queries, our key insight is that accurate knowledge on a sparse sample of frames is much more useful than inaccurate knowledge on all frames. This is opposite to existing designs that detect objects with low accuracy on all/most frames as capturing them [51, 40]. On a small sample of captured video frames dubbed landmarks, the camera runs generic, expensive object detection, e.g., YOLOv3 [77]. Constrained by camera hardware, landmarks are sparse in time, e.g., 1 in every 30 seconds; yet, with high-accuracy object labels, they provide reliable spatial distributions of various objects over long videos. High accuracy is crucial, as we will validate through evaluation ($\S$8.3). DIVA optimizes queries with landmarks: it prioritizes processing of frame regions with object skewness learned from landmarks; it bootstraps operators with landmarks as training samples. Landmarks only capture a small fraction of object instances; those uncaptured do not affect correctness/accuracy (§4).

• •

To execute queries: multipass processing with online operator upgrade (Figure 2(b)) To process large videos, our key insight is to refine query results in multiple passes, each pass with a more expensive/accurate operator. Unlike prior systems processing all frames in one pass and delivering results in one shot [59, 40, 58], multipass processing produces useful results during query execution, enabling users to explore videos effectively. To do so, DIVA’s cloud trains operators with a wide spectrum of accuracies/costs. Throughout query execution, the cloud keeps pushing new operators to the camera, picking the next operator based on query progress, network conditions, and operator accuracy. The early operators quickly explore the frames for inexact answers while later operators slowly exploit for more exact answers.

On 720-hour videos in total from 15 different scenes, DIVA runs queries at more than 100$\times$ video realtime on average, with typical wireless conditions and low-cost hardware. DIVA returns results quickly: compared to executing a query to completion, DIVA takes one order of magnitude shorter time to return half of the result frames. Compared to competitive alternatives, DIVA speeds up queries by at least 4$\times$.

Contributions

We have made the following contributions.

• •

Zero streaming, a new model for low-cost cameras to operate on frugal networks while answering video queries.

• •

Two novel techniques for querying zero-streaming cameras: optimizing queries with accurate knowledge from sparse frames; processing frames in multiple passes with operators continuously picked during a query.

• •

DIVA, a concrete implementation that runs queries at more than 100$\times$ realtime with uncompromised query accuracy. To our knowledge, DIVA is the first system designed for querying large videos stored on low-cost remote cameras.

Ethical considerations

In this study: all visual data used is from the public domain; no information traceable to human individuals is collected or analyzed.

2 Motivations

2.1 Cold videos are already pervasive

Case study: Cold videos in real-world deployment

We conduct an IRB-approved study examining existing camera deployment on PKU campus. Spanning 1 mi2, the campus hosts tens of thousands of employees and operates more than 1,000 cameras. All captured videos are stored for a few months for retrospective queries before deletion. The camera deployment supports AI-based queries, e.g., object detection, not traceable to unique persons, and reviews by human analysts. We analyzed system logs spanning six continuous months: in over 3,000,000 hours of videos (5.4 PB) have been captured, only <0.005% video data from <2% cameras are queried.

Why are most videos cold?

(1) Interesting video events are both unpredictable (thus the need for capturing excessive videos) and sparse (thus low chances for footage being queried). For example, severe traffic breakdown contributes to less than 5% of the time per day [89]; Foreign intelligence surveillance court only reviewed a tiny fraction of video for terrorism events [93]. (2) Analyzing videos is expensive: it still requires a GPU of a few thousand dollars for high-accuracy object detection over a video stream [59]. (3) In years to come, cheap cameras will produce more videos.

2.2 Target queries and their execution

We target ad-hoc queries [51, 59, 96, 100]. The query parameters, including object classes, video timespans, and expected accuracies, are specified at query time rather than video capture time. Such queries are known for flexibility.

High-accuracy object detection is essential

Object detection is the core of ad-hoc queries [58]. Minor accuracy loss in object detection may result in substantial loss in query performance, as we will demonstrate in $\S$8. While NNs significantly advance object detection, new models with higher accuracy demand much more compute. For instance, compared to YOLOv3 (2018) [77], CornerNet (2019) [64] improves Average Precision by 28% while being 5$\times$ more expensive.

Low-cost cameras cannot answer queries without cloud

Cameras in real-world deployment are reported to be resource-constrained [65]. Low-cost cameras (<40) have wimpy cores, e.g., Cortex-A9 cores for YI Home Camera [[18](#bib.bib18)] and MIPS32 cores for WyzeCam [[17](#bib.bib17)]; their DRAM is no more than a few GBs [[16](#bib.bib16), [15](#bib.bib15)]. In recent benchmarks, they run state-of-the-art object detection at 0.1 FPS [[66](#bib.bib66), [8](#bib.bib8)], incapable of keeping up with video capture at 1–30 FPS [[51](#bib.bib51), [59](#bib.bib59)]. NN accelerators still cannot run high-accuracy object detection fast enough at low enough monetary cost, e.g., Intel’s Movidius (70) runs YOLOv3 at no faster than 0.5 FPS. In the foreseeable future, we expect that the resource gap between high-accuracy object detection and low-cost camera continues to exist.

2.3 A case for zero streaming

Streaming cold videos wastes bandwidth

As discussed in $\S$1, cameras are cheap while wireless spectrum is precious. Deploying streaming cameras on a shared network incurs poor experience [3, 11] and draws researcher attention [100, 40]. Dedicated networks are costly [14] and thus only suit a small number of cameras in critical locations. While wireless bandwidth grows, consumer demand grows even faster, e.g., 20$\times$ for VR/AR and 10$\times$ for gaming [5]. Cold video traffic should not contend with consumers for network bandwidth.

Streaming optimizations cannot offset the waste

One may reduce FPS or resolution of streamed videos. Even if users tolerate the resultant lower query accuracy, the saved bandwidth is incomparable to the waste on overwhelmingly streamed cold videos, as we will experimentally show (§8). On-camera “early filters”  [40, 65, 42] are still suboptimal when querying massive cold videos. (1) Without knowing query objects/parameters at video capture time, a camera may run a generic filter, e.g., discarding no-motion frames; it still streams substantial survival frames (e.g., consider a street-view camera). As stated above, most of these frames will remain cold and hence wasted. (2) The camera may run a large set of specific filters covering all possible query objects/parameters. Even if possible, this incurs a much higher compute cost to camera.

Edge processing does not justify streaming

Cameras may stream to edge servers. Yet, streaming hundreds if not thousands of always-on, cold video streams, even if possible on certain wireless infrastructures, still wastes precious wireless spectrum at the edge [69]. Furthermore, deploying and managing video edge servers can be challenging and costly in many scenarios, such as construction sites and remote farms.

Cameras can retain videos long enough

Table 1 shows the price of $\mu$SD cards has been dropped by 2.6$\times$–5.4$\times$ in the past few years. Cameras can retain videos for several weeks and for several months soon. Such a retention period is already adequate for most retrospective query scenarios, where videos are retained from a few weeks to a few months based on best practice and legal regulations [2, 10, 7, 1]. For privacy, many regulations prohibit video retention longer than a few months and mandate deletion afterwards [7, 1].

Our model & design scope

To harness cold videos, we advocate for zero streaming. We focus on cold videos being queried for the first time and querying individual cameras. We intend our design to form the basis of future enhancement and extension, e.g., resource scheduling for multiple queries/users/tenants [40], caching for repetitive queries [95], exploiting past queries for refinement [41], and exploiting cross-camera topology [54]. We address limited compute resource on cameras [15] and limited network bandwidth [47]. We do not consider the cloud as a limiting factor, assuming it runs fast enough to process frames uploaded from cameras.

3 The DIVA Overview

Query types

Concerning a specific camera, an ad-hoc query ($\mathcal{T,C}$) covers a video timespan $\mathcal{T}$, typically hours or days, and an object class $\mathcal{C}$ as detectable by modern NNs, e.g., any of the 80 classes of YOLOv3 [77]. As summarized in Table 2, DIVA supports three query types: Retrieval, e.g., “retrieve all images that contain buses from yesterday”; Tagging, e.g., “return all time ranges when any deer shows up in the past week”, in which the time ranges are returned as metadata but not images; Counting, e.g., “return the maximum number of cars that ever appear in any frame today”.

System components

DIVA spans a camera and the cloud. Between them, the network connection is only provisioned at query time. To execute a query, a camera runs lightweight NNs, or operators, to filter or rank the queried frames for upload. On the uploaded frames, the cloud runs generic, high-accuracy object detection and materializes query results. Table 2 summarizes executions for different queries:

$\bullet$ The camera executes rankers for Retrieval and max Count queries. A ranker scores frames; a higher score suggests that a frame is more likely to contain any object of interest (for Retrieval) or a large count of such objects (for max Count).

$\bullet$ The camera executes filters for Tagging queries. A filter scores frames; it resolves any frame scored below/above two pre-defined thresholds as negative/positive, and deems other frames as unresolved. For each resolved frame, the camera uploads a positive/negative tag; the camera either uploads unresolved frames for the cloud to decide or defer them to more accurate filters on camera in subsequent passes.

Query execution

Upon receiving a query, the cloud retrieves all landmarks in queried video as low-resolution thumbnails, e.g., 100$\times$100, with object labels and bounding boxes (Figure 3
1 ). The cloud uses landmarks: (1) to estimate object spatial distribution, e.g., “90% queried objects appear in a 100$\times$100 region on the top-right”, which is crucial to query optimization (§4); (2) as the initial training samples for bootstrapping a family of camera operators ( 2 ). The camera filters/ranks frames and uploads the ranked or surviving frames ( 3 ). The cloud processes the uploaded frames and emits results, e.g., positive frames. It trains operators for higher accuracy ( 4 ). Observing resource conditions and positive ratios in uploaded frames, the cloud upgrades the operator on camera ( 5 ). With the upgraded operator, the camera continues to process remaining frames ( 6 ). Step ( 4 )–( 6 ) repeat until query abort or completion. Throughout the query, the cloud keeps refining the results presented to the user ( 7 ).

Notable designs

(1) The camera processes frames in multiple passes, one operator in each pass. (2) The camera processes and uploads frames asynchronously. For instance, when the camera finishes ranking 100 out of total 1,000 frames, it may have uploaded the top 50 of the 100 ranked frames. This is opposed to common ranking which holds off frame upload until all the frames are ranked [53, 38, 61]. (3) The processing/upload asynchrony facilitates video exploration: it amortizes query delay over many installments of results; it pipelines query execution with user thinking [45]. Table 2 summarizes a user’s view of query results and the performance metrics. While such online query processing has been known [43, 71], we are the first applying it to visual data.

Limitations

DIVA is not designed for several cases and may underperform: querying very short video ranges, e.g., minutes, for which simply uploading all queried frames may suffice without operators; querying non-stationary cameras for which landmarks may not yield accurate object distribution. DIVA is vulnerable to loss of video data in case of camera storage failure. Users can mitigate such a risk via cross-camera data backup (RAID-like techniques) on the same local area network or by increasing camera deployment density.

4 Landmark Design

Surveillance cameras have a unique opportunity: to learn object class distribution from weeks of videos. We focus on spatial skews: objects of a given class are likely to concentrate on certain small regions on video frames. In examples of Figure 4(a)-(b), most cars appear near a stop sign; most persons appear in a shop’s aisle. Such long-term skews are rarely tapped in prior computer vision work, which mostly focused on minute-long videos [52, 54, 78, 102, 81]. Compared to recent work that improved classifier performance by cropping video frames [40], DIVA takes a step further by automatically learning spatial skews from sparse frames with resource efficiency.

The design is backed up by three key observations. (1) One object class may exhibit different skews in different videos (Figure 4(a)-(c)); different classes may exhibit different skews in the same video (Figure 4(c)). (2) The skews are pervasive: surveillance cameras cover long time spans and a wide field of view, where objects are small; in the view, objects are subject to social constraints, e.g., buses stop at traffic lights, or physical constraints, e.g., humans appear on the floor. (3) The skews can be learned through sparse frame samples, as exemplified by Figure 5.

To exploit such an opportunity, DIVA makes the following design choices. High-accuracy object detection: at capture time, the camera runs an object detector with the highest accuracy as allowed by the camera’s hardware, mostly memory capacity. This is because camera operators crucially depend on the correctness of landmarks, i.e., the object labels and bounding boxes. We will validate this experimentally ($\S$8.3). Sparse sampling at regular intervals: to accommodate slow object detection on cameras, the camera creates landmarks at long intervals, e.g., 1 in every 30 seconds in our prototype (§8). Sparse sampling is proven valid for estimating statistics of low-frequency signals [37], e.g., object occurrence in videos in our case. We will validate this ($\S$8.3); without assuming a priori of object distribution, regular sampling ensures unbiased estimation of the distribution [79]. Given a priori, cameras may sample at corresponding random intervals for unbiased estimation.

Key idea: exploiting spatial skews for performance

The cloud learns the object class distribution from landmarks of the queried video timespan. It generates a heatmap for spatial distribution (Figure 4). Based on the heatmap, the cloud produces camera operators consuming frame regions of different locations and sizes. Take Figure 4(a) as an example: a filter may consume bottom halves of all frames and accordingly filter frames with no cars; for Figure 4(b), a ranker may consume a smaller bounding box where 80% persons appear and rank frames based on their likelihood of containing more persons. Figure 6 shows that, by zooming into smaller regions, operators run faster and deliver higher accuracy. By varying input region locations/sizes, DIVA produces a set of operators with diverse costs/accuracies. By controlling the execution order of operators, DIVA processes “popular” frame regions prior to “unpopular” regions. DIVA never omits any region when it executes a query to completion to guarantee correctness.

What happens to instances uncaptured by landmarks?

Sparse by design, landmarks are not meant to capture all object instances; instead, they are used as inexact estimators and initial training samples. Reducing landmarks will degrade query speed, as we will experimentally quantify in $\S$8.3. Doing so, however, does not affect query correctness or accuracy: the instances uncaptured by landmarks will be eventually processed by DIVA as a query goes on.

5 Online Operator Upgrade

5.1 The rationale

Three factors determine a query’s execution speed:

Pending workloads: the difficulty of the frames to be processed, i.e., how likely will the frame be mis-filtered or mis-ranked on camera. 2. 2.

Camera operators: cheap operators spend less time on each frame but are more likely to mis-filter/mis-rank frames, especially difficult frames. This is shown in Figure 6. 3. 3.

Network condition: the available uplink bandwidth.

The three factors interplay as follows.

$\bullet$ Queries executed with on-camera rankers   A camera ranks and uploads frames asynchronously (§3). The key is to maximize the rate of true positive frames arriving at the cloud, for which the system must balance ranking speed/accuracy with upload bandwidth. (1) When the camera runs a cheaper ranker, it ranks frames at a much higher rate than uploading the frames; as a result, the cloud receives frames hastily selected from a wide video timespan. (2) When the camera runs an expensive ranker, the cloud receives frames selected deliberately from a narrow timespan. (3) The camera should never run rankers slower than upload, which is as bad as uploading unranked frames.

As an example, ECHEAP and EEXP on the top of Figure 7 compare two possible executions of the same query, running cheap/expensive rankers respectively. Shortly after the query starts ( 1 ), ECHEAP swiftly explores more frames on camera; it outperforms EEXP by discovering and returning more true positive frames. As both executions proceed to harder frames ( 2 ), ECHEAP makes more mistakes in ranking; it uploads an increasingly large ratio of negatives which wastes the execution time. By contrast, EEXP ranks frames slower yet with much fewer mistakes, hence uploading fewer negatives. It eventually returns all positives earlier than ECHEAP ( 3 ).

The microbenchmark in Figure 8(a) offers quantitative evidence. E1 spends less time (0.7$\times$) in returning the first 90% positives, but more time (1.7$\times$) in returning 99% positives. Furthermore, lower upload bandwidth favors a more expensive ranker, as the uploaded frames would contain a higher ratio of positives, better utilizing the precious bandwidth.

$\bullet$ Queries executed with on-camera filters   The key is to maximize the rate of resolving frames on camera. Cheap filters excel on easy frames, resolving these frames fast with confidence. They are incapable on difficult frames, wasting time on attempting frames without much success in resolving. They would underperform expensive filters that spend more time per frame yet being able to resolve more frames.

The benchmark in Figure 8(b) shows two executions with cheap/expensive filters. Early in the query, E1 makes faster progress as the camera quickly resolves 50% of the frames (4$\times$ less time than E2). Later in the execution, E1 lags behind as the camera cannot resolve the remaining frames and must upload them. By contrast, E2 resolves 82% of frames on camera and only uploads the remaining 18%. As a result, E2 takes 1.3$\times$ less time in completing 90% and 99% of the query.

Summary & implications

It is crucial for DIVA to pick operators with optimal cost/accuracy at query time. The choice not only varies across queries but also varies throughout a query’s execution: easy frames are processed early, leaving increasingly difficult frames that call for more expensive operators. DIVA should monitor pending frame difficulty and network bandwidth and upgrade operators accordingly.

5.2 Multipass, multi-operator execution

DIVA manages operators with the following techniques.

(1) A camera processes frames iteratively with multiple operators.

(2) The cloud progressively updates operators on camera, from cheaper ones to more expensive ones, as the direction shown in Figure 6. In picking operators, the cloud dynamically adapts operator speed to frame upload speed.

(3) The cloud uses frames received in early execution stages to train operators for later stages; as the latter operators are more expensive, they require more training samples.

$\bullet$ Multipass ranking This is exemplified by the bottom execution in Figure 7. The camera first runs a cheap ranker, moving positives towards the front of the upload queue ( 4 ). Subsequently, the camera runs an expensive ranker, continuously reordering unsent frames in a smaller scope ( 5 ). Throughout the query, the camera first quickly uploads easy frames that are quickly ranked and slows down to vet difficult frames with expensive/accurate ranking. Notably, the cheaper ranker roughly prioritizes the frames as input for the expensive ranker, ensuring the efficacy of the expensive ranker. In actual query executions, a camera switches among 4–8 operators (§8).

$\bullet$ Multipass filtering The camera sifts undecided, unsent frames in multiple passes, each with a more expensive filter over a sample of the remaining frames. Throughout one query, early, cheaper filters quickly filter easier frames, leaving more difficult frames for subsequent filters to resolve.

6 Query Execution Planning

DIVA plans a concrete query execution by (1) the camera’s policy for selecting frames to process; (2) the cloud’s policy for upgrading on-camera operators. We now discuss them.

6.1 Executing Retrieval queries

Policy for selecting frames

To execute the initial operator, the camera prioritizes fixed-length video spans (e.g., 1 hour) likely rich in positive frames, estimated based on landmark frames. In executing subsequent operators, the camera processes frames in their existing ranking as decided by earlier operators, as described in $\S$5. The camera gives opportunities to frames never ranked by prior operators, interleaving their processing with ranked frames with mediocre scores (0.5).

Policy for operator upgrade

As discussed in $\S$3, DIVA switches from cheap operators to expensive ones, and matches operator speed to frame upload rate. To capture an operator $op$’s relative speed to upload, it uses one simple metric: the ratio between the two speeds, i.e., $f_{op}$ = $FPS_{op}/FPS_{net}$. Operators with higher $f_{op}$ tend to rapidly explore frames while others tend to exploit slowly. The operator speed $FPS_{op}$ is profiled offline. (1) Selecting the initial operator In general, DIVA should fully utilize the upload bandwidth with positive frames. As positive frames are scattered in the queried video initially, the camera should explore all frames sufficiently fast. Otherwise, it would either starve the uplink or knowingly upload negative frames. Based on this idea, the cloud picks the most accurate operator from the ones that are fast enough, i.e., $f_{op}\times R_{pos}>1$, where $R_{pos}$ is the ratio of positives in the queried video, estimated from landmarks. (2) When to upgrade: current operator losing its vigor The cloud upgrades operators either when the current operator finishes processing all frames, or the cloud observes a continuous quality decline in recently uploaded frames, an indicator of the current operator’s incapability. To decide the latter, DIVA employs a rule: the positive ratio in recently uploaded frames are $k\times$ (default: 5) lower than the frames uploaded at the beginning; (3) Selecting the next operator: slow down exponentially Since the initial operator promotes many positives towards the front of the upload queue, subsequent operators, scanning from the queue front, likely operate on a larger fraction of positives. Accordingly, the cloud picks the most accurate operator among much slower ones, s.t. $f_{op(i+1)}>\alpha\times f_{op(i)}$, where $\alpha$ controls speed decay in subsequent operators. A larger $\alpha$ leads to more aggressive upgrade: losing more speed for higher accuracy. In the current prototype, we empirically choose $\alpha=0.5$. Since $f$ is relative to $FPS_{net}$ measured at every upgrade, the upgrade adapts to network bandwidth change during a query.

6.2 Executing Tagging queries

Recall that for Tagging, a camera runs multipass filtering; the objective of each pass is to tag, as positive ($P$) or negative ($N$), at least one frame from every K adjacent frames. We call $K$ the group size; DIVA pre-defines a sequence of group sizes as refinement levels, e.g., $K$ = 30, 10, …, 1. As in prior work [59, 51, 58], the user specifies tolerable error as part of her query, e.g., 1% false negative and 1% false positive; DIVA trains filters with thresholds to meet the accuracy.

Policy for selecting frames

The goal is to quickly tag easy frames in individual groups while balancing the workloads of on-camera processing and frame upload. An operator $op$ works in two stages of each pass. i) Rapid attempting. $op$ scans all the groups; it attempts one frame per group; if it succeeds, it moves to the next group; it adds undecidable frames ($U$) to the upload queue. ii) Work stealing. $op$ steals work from the end of upload queue. For an undecidable frame $f$ belonging to a group $g$, $op$ attempts other untagged frames in $g$; once it succeeds, it removes $f$ from the upload queue as $f$ no longer needs tagging in the current pass. After one pass, the camera switches to the next refinement level (e.g., 10 $\rightarrow$ 5). It keeps all the tagging results ($P$,$N$,$U$) while cancels all pending uploads. It re-runs the frame scheduling algorithm until it meets the finest refinement level or query terminated.

Policy for operator upgrade

Given an operator $op$ and $\gamma_{op}$, the ratio of frames it can successfully tag, DIVA measures $op$’s efficiency by its effective tagging rate, $FPS_{op}\times\gamma_{op}+FPS_{net}$, as a sum of $op$’s successful tagging rate and the uploading rate. As part of operator training, the cloud estimates $\gamma_{op}$ for all the candidate operators by testing them on all landmarks (early in query) and uploaded frames (later in query). To select every operator, initial or subsequent, the cloud picks the candidate with the highest effective tagging rate. The cloud upgrades operators either when the current operator has attempted all remaining frames or another candidate having an effective tagging rate $\beta\times$ or higher (default value 2).

6.3 Executing Counting queries

Max Count: Policy for selecting frames

To execute the initial operator, the camera randomly selects frames to process, avoiding the worst cases that the max resides at the end of the query range. For subsequent operators, the camera processes frames in existing ranking decided by earlier operators.

Max Count: Policy for operator upgrade

As the camera runs rankers, the policy is similar to that for Retrieval with a subtle yet essential difference. To determine whether the current operator shall be replaced, the cloud must assess the quality of recently uploaded frames. While for Retrieval, DIVA conveniently measures the quality as the ratio of positive frames, the metric does not apply to max Count, which seeks to discover higher scored frames. Hence, DIVA adopts the Manhattan distance as a quality metric among the permutations from the ranking of the uploaded frames (as produced by the on-camera operator) and the ranking that is re-computed by the cloud object detector. A higher metric indicates worse quality hence more urgency for the upgrade.

Average/Median Count: no on-camera operators

After the initial upload of landmarks, the camera randomly samples frames in queried videos and uploads them for the cloud to refine the average/median statistics. To avoid any sampling bias, the camera does not prioritize frames; it instead relies on the Law of Large Numbers (LLN) [48] to approach the average/median ground truth through continuous sampling.

7 Implementation and Methodology

Operators

We architect on-camera operators as variants of AlexNet [63]. We vary the number of convolutional layers (2–5), convolution kernel sizes (8/16/32), the last dense layer’s size (16/32/64); and the input image size (25$\times$25/50$\times$50/100$\times$100). We empirically select 40 operators to be trained by DIVA online; we have attempted more but see diminishing returns. These operators require small training samples (e.g., 10K images) and run fast on camera.

Background subtraction filters static frames at low overhead [51]. DIVA employs a standard technique [12]: during video capture, a camera detects frames that have little motion (< 1% foreground mask) and omits them in query execution. On our camera hardware (Table 3), background subtraction is affordable in real time during capture. For fair comparisons, we augment all baselines with background subtraction.

Videos & Queries

We test DIVA on 15 videos captured from 15 live camera feeds (Table 4). Each video lasts continuous 48 hours including daytime and nighttime, collected between Oct. 2018 to Mar. 2019. We preprocess all videos to be 720P at 1 FPS, consistent with prior work [51]. We test Retrieval/Tagging/Counting queries on 6/6/3 videos. We intentionally choose videos with disparate characteristics and hence different degrees of difficulty. For instance, Whitebay is captured from a close-up camera, containing clear and large persons; Venice is captured from a high camera view and hence contains blurry and small persons. For each video, we pick a representative object class to query; across videos, these classes are diverse.

For Tagging, we set query error to be $<$ 1% FN/FP as prior work did [59].

A query’s accuracy is reflected by its execution progress. For retrieval/counting, we report accuracy as the fraction of positive frames returned. There is no false positive because the cloud always runs the high-accuracy object detector as a “safety net”, of which the output is regarded as the ground truth. For tagging, we report accuracy as query errors, meaning the percentage of frames mistakenly tagged. To issue a query, the user sets the target error, which by default is 1% as in prior work. Table 2 and $\S$6 provide more details.

Test platform & parameters

As summarized in Table 3(a), we test on embedded hardware similar to low-cost cameras [15, 16]. We use Rpi3 as the default camera hardware and report its measurement unless stated otherwise. During query execution, both devices set up a network connection with 1MB/s default bandwidth to emulate typical WiFi condition [47]. Note that this network bandwidth is not meant for streaming; it is only for a camera while the camera is being queried. We run YOLOv3 as the high-accuracy object detector on camera and cloud (Table 3(b)). In calculating accuracy, we use the output of YOLOv3 as the ground truth as in prior work [59, 51]. On Rpi3, we partition YOLOv3 into three stages, each fitting into DRAM separately.

We will study alternative models, landmarks, and resources in $\S$8.3.

Baselines

As summarized in Table 3(b), we compare DIVA with three alternative designs augmented with background subtraction and only process/transmit non-static video frames.

• •

CloudOnly: a naive design that uploads all queried frames at query time for the cloud to process.

• •

OptOp: in the spirit of NoScope [59], the camera runs only one ranker/filter specialized for a given query, selected by a cost model for minimizing full-query delay. To make OptOp competitive, we augment it with landmark frames to reduce the operator training cost. Compared to DIVA, OptOp’s key differences are the lack of operator upgrade and the lack of operator optimization by long-term video knowledge.

• •

PreIndexAll: in the spirit of Focus [51], the camera runs a cheap yet generic object detector on all frames. We pick YOLOv3-tiny (much cheaper than YOLOv3) as the detector affordable by Rpi3 in real time (1 FPS). The detector plays the same role as an operator in DIVA, except that it runs at capture time: for Retrieval and Counting, the detector’s output scores are used to prioritize frames to upload at query time; for Tagging, the output is used to filter the frames that have enough confidence. PreIndexAll implements all run-time features of Focus except feature clustering. We left out clustering because we find it performs poorly on counting queries. Compared to DIVA, PreIndexAll’s key differences are: it answers queries solely based on the indexes built at capture time; it requires no operator training or processing actual images at query time.

8 Evaluation

8.1 End-to-end performance

Full query delay

is measured as: (Retrieval) the time to receive 99% positive frames as in prior work [51]; (Tagging) the time taken to tag every frame; (Counting) the time to reach the ground truth (max) or converge within 1% error of the ground truth (avg/median). Overall, DIVA delivers good performance and outperforms the baselines significantly.

• •

Retrieval (Figure 9(a)). On videos each lasting 48 hours, DIVA spends $\sim$1,900 seconds on average, i.e., 89$\times$ of video realtime. On average, DIVA’s delay is 3.8$\times$, 3.1$\times$, and 2.0$\times$ shorter than CloudOnly, PreIndexAll, and OptOp, respectively.

• •

Tagging (Figure 9(b)). DIVA spends $\sim$581 seconds on average (297$\times$ realtime). This delay is 16.0$\times$, 2.1$\times$, and 4.3$\times$ shorter than CloudOnly, PreIndexAll, and OptOp, respectively.

• •

Counting (Figure 10). DIVA’s average/median take several seconds to converge. For average Count, DIVA’s delay is 65.1$\times$ and up to three orders of magnitude shorter than CloudOnly and PreIndexAll. For median Count, DIVA’s delay is 68.3$\times$ shorter than the others. For max Count, DIVA spends 34 seconds on average (635$\times$ realtime), which is 5.8$\times$, 5.0$\times$, and 1.3$\times$ shorter than CloudOnly, PreIndexAll, and OptOp.

Query progress

DIVA makes much faster progress in most time of query execution. It always outperforms CloudOnly and OptOp during Retrieval/Tagging (Figure 9). It always outperforms alternatives in median/average count (Figure 10).

Why DIVA outperforms the alternatives?

The alternatives suffer from the following.

(1) Inaccurate indexes. PreIndexAll resorts to inaccurate indexes (YOLOv3-tiny) built at capture time. Misled by them, Retrieval and Tagging upload too much garbage; Counting includes significant errors in the initial estimation, slowing down convergence.

(2) Lack of long-term knowledge. OptOp’s operators are either slower or less accurate than DIVA, as illustrated in Figure 6.

(3) One operator does not fit an entire query. Optimal at some point (e.g., 99% Retrieval), the operator runs too slow on easy frames which could have been done by cheaper operators.

Why DIVA underperforms (occasionally)?

On short occasions, DIVA may underperform PreIndexAll at early query stages, e.g., BoatHouse in Figure 9. Reasons: (1) PreIndexAll’s inaccurate indexes may be correct on easy frames; (2) PreIndexAll does not pay for operator bootstrapping as DIVA. Nevertheless, PreIndexAll’s advantage is transient. As easy frames are exhausted, indexes make more mistakes on the remaining frames and hence slow down the query.

Can DIVA outperform under different network bandwidths at query time?

Table 5 summarizes DIVA’s query delays at 9 bandwidths evenly spaced in [0.1 MB/s, 10 MB/s] which cover typical WiFi bandwidths [9]. We have observed that: on lower bandwidths, DIVA’s advantages over baselines are more significant; at high bandwidths, DIVA’s advantages are still substantial (>2$\times$ in most cases) yet less pronounced. The limitation is not in DIVA’s design but rather its current NNs: we find it difficult to train operators that are both fast enough to keep up with higher upload bandwidth and accurate enough to increase the uploaded positive ratio proportionally.

vs. “all streaming”: query speed

As “all streaming” uploads all videos to the cloud before a query starts, the query speed is bound by cloud GPUs but not network bandwidth. With our default experiment setting (1 GPU and 1MB/s network bandwidth), “all streaming” still runs queries much slower than zero streaming. Adding more cloud GPUs will eventually make “all streaming” run faster than DIVA.

vs. “all streaming”: network bandwidth saving

Compared to streaming all videos (720P 1FPS) at capture time, DIVA saves traffic significantly, as shown in Figure 11. When only as few as 0.005% of video is queried as in our case study (§2), the saving is over three orders of magnitude. Even if all captured videos are queried, DIVA saves more than 10$\times$, as its on-camera operators skip uploading many frames. Among the bandwidth reduction brought by DIVA, only less than 30% attributes to the background subtraction technique. It shows that the disadvantage of “all streaming” is fundamental: streaming optimizations may help save the bandwidth (upmost several times [96]) but cannot offset the waste, as discussed in $\S$2.3.

Training & shipping operators

For each query, DIVA trains $\sim$40 operators, of which $\sim$10 are on the Pareto frontier. The camera switches among 4–8 operators, which run at diverse speeds (27$\times$–1,000$\times$ realtime) and accuracies. DIVA chooses very different operators for different queries. Training one operator typically takes 5–45 seconds on our test platform and requires 5k frames (for bootstrapping) to 15k frames (for stable accuracy). Operators’ sizes range from 0.2–15 MB. Sending an operator takes less than ten seconds. Only the delay in training and sending the first operator ($\leq$ 40 seconds) adds to the query delay which is included in Figure 9/10. Subsequent operators are trained and transmitted in parallel to query execution. Their delays are hidden from users.

DIVA elasticity Due to DIVA’s design, the computing resources available on low-cost cameras are used efficiently at both capture and query time. Thanks to its elastic execution, it can avoid interference with a camera’s surveillance task, notably video encoding and storage. For instance, DIVA can produce denser/sparser landmarks per its CPU time allocated by the camera OS. According to our experiments on Raspberry Pi 3B+, recording video at 720P and 30 FPS only uses less than 2% of CPU time, which is negligible as compared to NN execution. We reserve a small fraction of CPU time to surveillance using cgroup and observe no frame drop in the surveillance task and negligible slowdown in NN execution.

8.2 Validation of query execution design

The experiments above show DIVA’s substantial advantage over OptOp, coming from a combination of two techniques – optimizing queries with long-term video knowledge (“Long-term opt”, §4) and operator upgrade (“Upgrade”, §5). We next break down the advantage by incrementally disabling the two techniques in DIVA. Figure 12 shows the results.

Both techniques contribute to significant performance. For instance, disabling Upgrade increases the delay of retrieving 90% instances by 2$\times$ and that of tagging 1/1 frames by 2$\times$-3$\times$. Further disabling Long-term Opt increases the delay of Retrieval by 1.3$\times$-2.1$\times$ and that of tagging by 1.6$\times$-3.1$\times$. Both techniques disabled, DIVA still outperforms CloudOnly with its single non-optimized operator.

Upgrade’s benefit is universal; Long-term opt’s benefit is more dependent on queries, i.e., the skews of the queried object class in videos. For instance, DIVA’s benefit is more pronounced on Chaweng, where small bicycles only appear in a region in 1/8 size of the entire frame, than Ashland, where large trains take 4/5 of the frame. With stronger skews in Chaweng, DIVA trains operators that are more accurate and run faster. This also accounts for DIVA’s varying (yet substantial) advantages over the alternatives (Figure 9).

8.3 Validation of landmark design

Next, we deviate from the default landmark parameters (Table 3) to validate the choice of sparse-but-sure landmarks.

DIVA hinges on accurate landmarks.

As shown in Figure 13(a), modestly inaccurate landmarks (as produced by YOLOv2; 48.1 mAP) increase delays for Q1/Q2 by 45% and 17%. Even less accurate landmarks (by YOLOv3-tiny; 33.1 mAP) increase the delays significantly by 5.3$\times$ and 4.3$\times$. Perhaps surprisingly, such inaccurate landmarks can be worse than no landmarks at all (“w/o LM” in Figure 13): when a query starts, a camera randomly uploads unlabeled frames for the cloud to bootstrap operators.   Why inaccurate landmarks hurt so much? They (1) provide wrong training samples; (2) lead to incorrect observation of spatial skews which further mislead frame cropping; and (3) introduce large errors into initial statistics, making convergence harder.

DIVA tolerates longer landmark intervals.

As shown in Figure 13(b), DIVA’s Retrieval and Tagging performance slowly degrade with longer intervals. Even with an infinite interval, i.e., “w/o LM” in Figure 13(a), the slowdown is no more than 3$\times$. On Counting, the performance degradation is more pronounced: 5$\times$ longer intervals for around 15$\times$ slow down. Yet, such degradation is still much smaller than one from inaccurate landmarks (two orders of magnitude). The reason is that, with longer LM intervals DIVA has to upload additional frames in full resolution ($\sim$10$\times$ larger than LMs) when a query starts for bootstrapping operators; such a one-time cost, however, is amortized over the full query.

Create the most accurate landmarks possible

Should a camera build denser yet less accurate landmarks or sparser yet more accurate ones? Figure 13(c) suggests the latter is always preferred, because of DIVA’s high sensitivity to landmark accuracy and low sensitivity to long landmark intervals.

DIVA on wimpy/brawny cameras

DIVA suits wimpy cameras that can only generate sparse landmarks. Some cameras may have DRAM smaller than a high-accuracy NN (e.g., $\sim$1 GB for YOLOv3); fortunately, recent orthogonal efforts reduce NN sizes [56]. Wimpier cameras will further disadvantage the alternatives, e.g., PreIndexAll will produce even less accurate indexes. On higher-end cameras (a few hundred dollars each [13]) that DIVA is not designed for, DIVA still shows benefits, albeit not as pronounced. High-end cameras can afford more computation at capture time. i) They may run PreIndexAll with improved index accuracy. In Figure 13(a), running YOLOv2 on all captured frames (PreIndexAll+Yv2), DIVA’s performance gain is 1.9$\times$ (left) or even 0.6$\times$ (right). ii) These cameras may generate denser landmarks and rely on the cloud for the remaining frames. Figure 13(b) shows, with one landmark every 5 seconds, DIVA’s advantage is 1.5$\times$.

9 Related Work

Optimizing video analytics

The CV community has studied video analytics for decades, e.g., for online training [83, 84] and active learning [57]. They mostly focus on improving analytics accuracy on short videos [78, 68, 102, 60, 44, 81] while missing opportunities in exploiting long-term knowledge (§4). These techniques alone cannot address the systems challenges we face, e.g., network limit or frame scheduling. A common theme of recent work is to trade accuracy for lower cost: VStore [96] does so for video storage; Pakha et al. [70] do so for network transport; Chameleon [55] and VideoStorm [99, 52] do so with video formats. DIVA’s operators as well exploit accuracy/cost tradeoffs. Multiple systems analyze archival videos on servers [73, 62, 96, 58, 80]. DIVA analyzes archival videos on remote cameras and embraces new techniques. ML model cascade is commonly used for processing a stream of frames [59, 85, 39]: in processing a frame, it keeps invoking a more expensive operator if the current operator has insufficient confidence. This technique, however, mismatches exploratory analytics, for which DIVA uses one operator to process many frames in one pass and produces inexact yet useful results for all of them.

Edge video analytics

To reduce cloud/edge traffic, computation is partitioned, e.g., between cloud/edge [97, 76, 40], edge/drone [91], and edge/camera [100]. Elf [94] executes counting queries completely on cameras. Most work targets live analytics, processes frames in a streaming fashion and trains NNs ahead of time. DIVA spreads computation between cloud/cameras but takes a disparate design point (zero streaming) that are inadequate in prior systems. CloudSeg [92] reduces network traffic by uploading low-resolution frames and recovering them via super resolution. DIVA eliminates network traffic at capture time at all.

Online Query Processing

Dated back in the 90s, online query processing allows users to see early results and control query execution [50, 49]. It is proven effective in large data analytics, such as MapReduce [43]. DIVA retrofits the idea for video queries and accordingly contributes new techniques, e.g., operator upgrade, to support the online fashion. DIVA could borrow UI designs from existing online query engines.

WAN Analytics

To query geo-distributed data, recent proposals range from query placement to data placement [88, 87, 86, 74, 90]. JetStream [75] adjusts data quality to meet network bandwidth; AWStream [98] facilitates apps to systematically trade-off analytics accuracy for network bandwidth. Like them, DIVA adapts to network; unlike them, DIVA does so by changing operator upgrade plan, a unique aspect in video analytics. DIVA targets resource-constrained cameras, which are unaddressed in WAN analytics.

10 Conclusions

Zero streaming shifts most compute from capture time to query time. We build DIVA, an analytics engine for querying cold videos on remote, low-cost cameras. At capture time, DIVA builds sparse but sure landmarks; at query time, it refines query results by continuously updating on-camera operators. Our evaluation of three types of queries shows that DIVA can run at more than 100$\times$ video realtime under typical wireless network and camera hardware.

Acknowledgments

Mengwei Xu was supported by National Key R&D Program of China under grant number 2020YFB1805500, the Fundamental Research Funds for the Central Universities, and National Natural Science Foundation of China under grant numbers 62032003, 61922017, and 61921003. Tiantu Xu and Felix Xiaozhu Lin were supported in part by NSF awards #1846102 and #1919197. We thank our shepherd, Michael Kozuch, and the anonymous ATC reviewers for their useful suggestions.