Random Notes
  • Introduction
  • Reading list
  • Theory
    • Index
      • Impossibility of Distributed Consensus with One Faulty Process
      • Time, Clocks, and the Ordering of Events in a Distributed System
      • Using Reasoning About Knowledge to analyze Distributed Systems
      • CAP Twelve Years Later: How the “Rules” Have Changed
      • A Note on Distributed Computing
  • Operating System
    • Index
  • Storage
    • Index
      • Tachyon: Reliable, Memory Speed Storage for Cluster Computing Frameworks
      • Exploiting Commutativity For Practical Fast Replication
      • Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS
      • Building Consistent Transactions with Inconsistent Replication
      • Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System
      • Spanner: Google's Globally-Distributed Database
      • Bigtable: A Distributed Storage System for Structured Data
      • The Google File System
      • Dynamo: Amazon’s Highly Available Key-value Store
      • Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications
      • Replicated Data Consistency Explained Through Baseball
      • Session Guarantees for Weakly Consistent Replicated Data
      • Flat Datacenter Storage
      • Small Cache, Big Effect: Provable Load Balancing forRandomly Partitioned Cluster Services
      • DistCache: provable load balancing for large-scale storage systems with distributed caching
      • Short Summaries
  • Coordination
    • Index
      • Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases
      • Paxos made simple
      • ZooKeeper: Wait-free coordination for Internet-scale systems
      • Just Say NO to Paxos Overhead: Replacing Consensus with Network Ordering
      • Keeping CALM: When Distributed Consistency is Easy
      • In Search of an Understandable Consensus Algorithm
      • A comprehensive study of Convergent and Commutative Replicated Data Types
  • Fault Tolerance
    • Index
      • The Mystery Machine: End-to-end Performance Analysis of Large-scale Internet Services
      • Gray Failure: The Achilles’ Heel of Cloud-Scale Systems
      • Capturing and Enhancing In Situ System Observability for Failure Detection
      • Check before You Change: Preventing Correlated Failures in Service Updates
      • Efficient Scalable Thread-Safety-Violation Detection
      • REPT: Reverse Debugging of Failures in Deployed Software
      • Redundancy Does Not Imply Fault Tolerance
      • Fixed It For You:Protocol Repair Using Lineage Graphs
      • The Good, the Bad, and the Differences: Better Network Diagnostics with Differential Provenance
      • Lineage-driven Fault Injection
      • Short Summaries
  • Cloud Computing
    • Index
      • Improving MapReduce Performance in Heterogeneous Environments
      • CLARINET: WAN-Aware Optimization for Analytics Queries
      • MapReduce: Simplified Data Processing on Large Clusters
      • Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks
      • Resource Management
      • Apache Hadoop YARN: Yet Another Resource Negotiator
      • Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center
      • Dominant Resource Fairness: Fair Allocation of Multiple Resource Types
      • Large-scale cluster management at Google with Borg
      • MapReduce Online
      • Delay Scheduling: A Simple Technique for Achieving Locality and Fairness in Cluster Scheduling
      • Reining in the Outliers in Map-Reduce Clusters using Mantri
      • Effective Straggler Mitigation: Attack of the Clones
      • Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing
      • Discretized Streams: Fault-Tolerant Streaming Computation at Scale
      • Sparrow: Distributed, Low Latency Scheduling
      • Making Sense of Performance in Data Analytics Framework
      • Monotasks: Architecting for Performance Clarity in Data Analytics Frameworks
      • Drizzle: Fast and Adaptable Stream Processing at Scale
      • Naiad: A Timely Dataflow System
      • The Dataflow Model:A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale
      • Interruptible Tasks:Treating Memory Pressure AsInterrupts for Highly Scalable Data-Parallel Program
      • PACMan: Coordinated Memory Caching for Parallel Jobs
      • Multi-Resource Packing for Cluster Schedulers
      • Other interesting papers
  • Systems for ML
    • Index
      • A Berkeley View of Systems Challenges for AI
      • Tiresias: A GPU Cluster Managerfor Distributed Deep Learning
      • Gandiva: Introspective Cluster Scheduling for Deep Learning
      • Workshop papers
      • Hidden Technical Debt in Machine Learning Systems
      • Inference Systems
      • Parameter Servers and AllReduce
      • Federated Learning at Scale - Part I
      • Federated Learning at Scale - Part II
      • Learning From Non-IID data
      • Ray: A Distributed Framework for Emerging AI Applications
      • PipeDream: Generalized Pipeline Parallelism for DNN Training
      • DeepXplore: Automated Whitebox Testingof Deep Learning Systems
      • Distributed Machine Learning Misc.
  • ML for Systems
    • Index
      • Short Summaries
  • Machine Learning
    • Index
      • Deep Learning with Differential Privacy
      • Accelerating Deep Learning via Importance Sampling
      • A Few Useful Things to Know About Machine Learning
  • Video Analytics
    • Index
      • Scaling Video Analytics on Constrained Edge Nodes
      • Focus: Querying Large Video Datasets with Low Latency and Low Cost
      • NoScope: Optimizing Neural Network Queriesover Video at Scale
      • Live Video Analytics at Scale with Approximation and Delay-Tolerance
      • Chameleon: Scalable Adaptation of Video Analytics
      • End-to-end Learning of Action Detection from Frame Glimpses in Videos
      • Short Summaries
  • Networking
    • Index
      • Salsify: Low-Latency Network Video through Tighter Integration between a Video Codec and a Transport
      • Learning in situ: a randomized experiment in video streaming
      • Short Summaries
  • Serverless
    • Index
      • Serverless Computing: One Step Forward, Two Steps Back
      • Encoding, Fast and Slow: Low-Latency Video Processing Using Thousands of Tiny Threads
      • SAND: Towards High-Performance Serverless Computing
      • Pocket: Elastic Ephemeral Storage for Serverless Analytics
      • Fault-tolerant and Transactional Stateful Serverless Workflows
  • Resource Disaggregation
    • Index
  • Edge Computing
    • Index
  • Security/Privacy
    • Index
      • Differential Privacy
      • Honeycrisp: Large-Scale Differentially Private Aggregation Without a Trusted Core
      • Short Summaries
  • Misc.
    • Index
      • Rate Limiting
      • Load Balancing
      • Consistency Models in Distributed System
      • Managing Complexity
      • System Design
      • Deep Dive into the Spark Scheduler
      • The Actor Model
      • Python Global Interpreter Lock
      • About Research and PhD
Powered by GitBook
On this page
  • Background
  • Motivation
  • Key insights
  • Chameleon
  • Comment

Was this helpful?

  1. Video Analytics
  2. Index

Chameleon: Scalable Adaptation of Video Analytics

https://people.cs.uchicago.edu/~junchenj/docs/Chameleon_SIGCOMM_CameraReady_faceblurred.pdf

PreviousLive Video Analytics at Scale with Approximation and Delay-ToleranceNextEnd-to-end Learning of Action Detection from Frame Glimpses in Videos

Last updated 5 years ago

Was this helpful?

Background

A typical video analytics application consists of a pipeline of video processing modules. The pipeline has several 'knobs' such as frame resolution, frame sampling rate, and detector model. A particular combination of knob values is referred as a configuration.

For example, in pipeline A the raw video frames are first pre-processed by sampling frames and resize them, and are then fed into one of several pre-trained object detection models(e.g., YOLO).

The choice of configuration impacts both the resource consumption and accuracy of the video application. For example, using high frame resolutions (e.g., 1080p) or NN models with many layers enables accurate detection of objects but also demands more GPU processing. Moreover, the best configuration for a video analytics pipeline also varies over time. For the traffic pipeline described above, we may use a low frame-rate during rush hours when cars are moving slowly.

Motivation

Prior video analytics systems profile the processing pipeline to minimize balance the resource and accuracy trade-off, but they only do it once. Specifically, they exhaustively profiles all configurations on the first x seconds of the video, picks the cheapest configuration that meets a predefined accuracy threshold, and stick with it for the whole duration of the video. However, as we hinted above, if the video content becomes more challenging(e.g. traffic moves faster), using the same configuration will negatively impact the accuracy. On the other hand, same configuration will waste resources if the video content is less challenging(e.g. at a traffic stop).

This limitation naturally leads us to periodically update the configurations(i.e., every t seconds). Unfortunately, profiling all configurations every T seconds is computationally prohibitive, which will negate the gains made by dynamically adapting the configuration.

Key insights

Persistent characteristics over time

While the characteristics of videos change over time, the underlying characteristics of the video objects (e.g., size, class, viewing angle) that affect accuracy tend to remain relatively stable over time. As a result, the best top-k best configurations tend to remain stable over time. Thus, we can dramatically reduce the search space by focusing on these top-k configurations, while periodically explore the full configuration space.

Cross-camera similarities

Video feeds that exhibit spatial correlations are abundant in practice. For example, the traffic cameras deployed in the same highway may be correlated, because the traffic tends to move in the same speed. Even if the cameras are not in geographic proximity, cameras deployed for the same purpose are also likely to exhibit similarities. We can leverage the fact that similar videos tend to have similar distributions of best configurations(i.e. same top-k configurations).

Independence of configuration knobs

The authors observed that, empirically, individual knobs have independent impact on accuracy and cost. This observation lets us prune a large part of the configuration space, which significantly reduce the profiling cost.

Chameleon

Chameleon periodically and profiles the video pipeline using an interval we refer to as the profiling window. Each profiling window is split into w smaller segments, each of which is a contiguous set of frames spanning a T-second interval. To leverage the temporal persistence, Chameleon only re-profile the configuration space on the first segment.

A "leader" video is profiled at the start of a "profiling window" and a set of good(top-k) configurations is found. This set is shared among "follower" videos who are similar to the leader. The initial grouping is done via an algorithm which will use k-means on the accuracy results of the initial profiling step.

Chameleon uses a solution inspired by greedy hill climbing that exploits the independence of NN configuration knobs to reduce the search space from exponential to linear. In greedy hill climbing, each knob is tuned while all other knobs are held fixed, reducing the search space to linear.

Comment

The paper provides very a good discussion and future work section. 1. Besides computational cost, network bandwidth is one of the key challenges in video analytics. Each stream coming in may be several orders of magnitude larger than the available bandwidth. To this end, FilterForward is one of the recent work that tries to save bandwidth by carefully selecting the video frames sent to the server. 2. Chameleon's design relied on a separate cluster for its periodic profiling so as to avoid any disruptions to live video analytics. 3. Although not mentioned in the paper, I doubt that, similar to NoScope, Chameleon is designed for fixed angle cameras. Thus, I think it is an interesting future work to explore the world of moving cameras.