Priority Progress CPU Adaptation for Elastic Real Time Applicat

1
Dr. Charles Krasic, Anirban Sinha and Lowell
Kirsh University of British Columbia,
Vancouver, Canada. Amazon Inc, Seattle, USA.
2
Motivation

• Multimedia capable networked devices are
  heterogeneous from powerful desktops to
  resource constricted mobile devices.
• In a single device, in addition to overall
  capabilities, there can be competition for
  resource sharing between various applications.

3
Motivation (Contd ...)

• Streaming media must be able to scale to the
  diversity of available hardware as well as time
  varying nature of available resources.
• Priority-Progress Streaming is a method for
  bandwidth-adaptive streaming.
• This paper apply the same basic
  Priority-Progress concepts toward making
  CPU-adaptive applications.

4
CPU Burstiness of Video
5
The Problem

• CPU requirements for a single video often vary
  greatly over the time, in correlation with
  bitrate.
• Device diversity and resource dynamics make over
  provisioning impractical.
• We need a mechanism for graceful adaptation
  hopefully maximizing quality (hence CPU)
  utilization its tough!

6
Adaptation Performance of Popular Video
Applications

• We take VLC and MPlayer and instrument them to
  measure their temporal fidelity measured using
  two matrices
• Jitter time delta between successive frame
  displays, captures visible playback stoppage.
• FPS - idea of overall smoothness of video.

7
Adaptation Performance of Popular Video
Applications (Contd ...)

• We play N simultaneous videos (all same video),
  in each of VLC and MPlayer for N 2 to 6
• We select two values of N Nsat that just
  saturates the CPU and N2 x sat which is twice the
  value of Nsat.
• Both VLC and MPlayer have some capability to
  adapt to higher CPU loads viz. through dropping
  of frames.
• We expect adaptation to occur in N2xsat case.
• For both players, we found Nsat 3 and thus N2 x
  sat 6

8
VLC MPlayer in underload
(a) VLC in underload for one single video
Total 3 videos (typical case for all videos)
(b) MPlayer in underload for one single video
Total 3 videos (typical case for all videos)
9
VLC and MPlayer in Underload Summary

• In under load, all players perform well MPlayer
  requires 14 less CPU than VLC.
• Jitter in underload is uninteresting because with
  FPS 24 and no frame dropping, basic jitter is
  approximately 41.7 ms in all cases.

10
VLC MPlayer in Overload FPS and Jitter for a
single video
(a) VLC in overload (one player out of 6)
(b) MPlayer in overoad (one player out of 6)
11
VLC MPlayer in Overload Fairness across videos
(a) VLC in overload All videos
(b) MPlayer in overoad All videos
12
VLC MPlayer in Overload Summary

• MPlayer exhibits bimodal fairness with some
  videos experiencing almost full frame rate and
  others experiencing very low frame rate.
• Overall MPlayer shows greater consistency towards
  frame dropping.
• Fairness for VLC across all videos is very poor.
• We suspect the differences between MPlayer and
  VLC as partly due to their architectural
  differences VLC is multithreaded whereas
  MPlayer is event driven.

13
Priority-Progress Decoding

• In this paper, we design, implement and evaluate
  Priority-Progress Decoding
• derives from our previous work on
  bandwidth-adaptive streaming
• Priority-Progress Streaming
• Sclalable Video codec, our variant of MPEG-4,
  called SPEG4
• Priority Mapper, translates declarative policies
  and raw video into appropriately prioritized ADUs
• Priority-Progress, adaptive streaming
  algorithm/protocol

14
Declarative Adaptation Policy Specification

• specify preferences instead of actions
• Specifications consists of a set of utility
  functions, one per quality dimension
• Mapper transforms policy specs into an executable
  adaptation strategy
• A streaming mechanism executes the adaptation

15
Priority-Progress Adaptation

• Take prioritized layered application data (SPEG
  mapper), and apply adapation window
• in original PPS, window did not slide, it does in
  PPD
• before resource constraint (Network, or CPU)
• take video with window boundaries (time based)
• re-order from original (time) order to priority
  order
• on completion of each step, re-order data into
  time order
• if time runs out, drop remaining low-priority
  data
• Ongoing work window scaling, spatial quality

16
QStream Performance with equal Utility
Specification
(a) QStream in underload (4 videos)
(b) QStream in overload (8 videos)
17
QStream Performance with Preferential Utility
Function Specified for Selected Video
(a) QStream in underload (4 videos)
(b) QStream in overload (8 videos, 1 boosted in
importance)
18
QStream Jitter in Overload and Underload.
(a) QStream in underload (4 videos)
(b) QStream in overload (8 videos)
19
QStream Results Summary

• QStream adapts gracefully and uniformly to
  increased CPU load across all videos.
• Jitter even in overload is reasonable and uniform
  and proportional to the number of frames dropped.
• QStream allows relative importance of streams to
  be specified allowing control over
  qualityregardless of complex resource
  implications.

20
Questions

• I am representing my supervisor Dr. Krasic who
  was supposed to present the work.
• I will try as best as I can to answer all your
  questions.
• For further information, please contact Dr.
  Krasic
• krasic_at_cs.ubc.ca
• http//qstream.org
• (all benchmark scripts and qstream source
  available open source)