Project Presentation

1
Project Presentation
2
Reminder

• 13th November 1 5pm
• Read your emails/Visit web sites for more
  information (later)

3
Reminder

• Please check your project title
• Please check your grades

4
Reviews Categories

• 4 categories
• No submission
• Did not demonstrate understanding
• Understand and summarize
• Understand, think and summarize

5
What I Hope You Have Learned

• How to read papers?
• How to evaluate papers?
• Think critically about what you read

6
Recent Papers

• from conferences

7
Sessions

• Session 1 Movies and Music
• Session 2 Peer-to-Peer Streaming
• Session 3 Power-Friendly

8
Movies and Music

• Session 1

9
Characterizing DVD

• Wu-Chi Feng et. al.
• Packet Video 2003

10
Motivations

• Lots of DVD videos available
• How are they encoded?
• What is the implications to our research?

11
DVD data

• 107 video streams
• 140 hours
• 80 DVDs

12
Bit-rates

• Maximum DVD bit rates 10 Mbps
• Found on DVD 3.3 7.8 Mbps
• VBR
• Quantization values change over time
• (only Spy Kids is CBR)

13
GOPs and Sequences

• Each GOP was encoded into a different sequence
• GOP sizes around 12 frames

14
Sequence

• sequence header
• width
• height
• frame rate
• bit rate

15
GOP Group of Picture

• gop header
• time

16
Picture

• pic header
• number
• type (I,P,B)

17
Frame Patterns

• Most videos have varying
• Number of frames within a GOP
• Frame patterns
• (ID4 has 134 unique GOP patterns)

18
Frame Pattern

• Scene Change Detection used extensively
• IPPPPPPP quite common!

19
Implication to Research

• Cannot assume fixed frame pattern
• Cannot always drop B frames

20
Network Musical Performances

• UC Berkeley
• NOSSDAV 2001

21
Goal

• Show that networked musical performances (NMP)
  can be done

22
Observation

• Stanford Berkeley (40 miles)
• RTT 4 ms
• 0.72 meters
• Berkeley Caltech (375 miles)
• RTT 28 ms
• 4.88 meters

23
Observation

• Musical instruments have long production latency

24
Observation

• Dont send audio, send command
• Keeps states of the current music performance

25
Example

• NoteOn(channel, note, velocity)
• NoteOff(channel, note)

26
Packet Loss Recovery

• Lost/Late NoteOn
• skipped
• Lost/Late NoteOff
• executed

27
Packet Loss Recovery

• Guard packets
• Recovery journals

28
Bandwidth

• 20 MIDI command per seconds
• 640 bps
• With recovery journals
• 7 kbps

29
Experience

• Lost/Late NoteOn/NoteOff
• But musician can adjust and play fluidly

30
Peer-to-Peer

• Session 2

31
P2Cast

• Yang Guo et. al.
• WWW 2003

32
Patching
Time
mcast
unicast
Client Request
33
Patching
Patching Window W
Time
mcast
mcast
Client Request
34
Problem with VOD

• IP Multicast usually assumed
• Patching still requires unicast connections

35
P2Cast
36
New Session
37
Existing Session Patch
Fat Pipe First
?
?
38
Patch Server Selection
39
Patching Stream
base stream
patching stream
40
Tree Example
41
Failure Recovery
X
42
Failure Recovery

• What if
• Patch server failed?
• Base server failed?

43
PROMISE

• Mohamed Hafeeda et. al.
• ACM MM 2003

44
Problem

• P2P with streaming
• One peer may not have enough bandwidth
• Need to aggregate multiple peers

45
Architecture
B/2
B/4
B/4
CollectCast
46
CollectCast

• Select sending peers
• Monitor network
• Assign streaming rates and data segments
• Decide when to change peers

47
PROMISE Operations
I want to watch LOTRT2T
48
PROMISE Operations
These are the candidates..
49
PROMISE Operations
Max expected goodness Subject to rate
constraints
50
PROMISE Operations
Here are your peers!
51
PROMISE Operations
Send these..
52
PROMISE Operations
Should I switch?
53
PALS

• Reza Rejaie et. al.
• NOSSDAV 2003

54
Problem

• P2P with streaming
• One peer may not have enough bandwidth
• Need to aggregate multiple peers
• Using layered coding
• With congestion control

55
Sliding Window
playout time
window
56
Packet Assignment
S1
S2
playout time
57
Sending Mechanism

• Request packets in priority order
• Sender must send in order
• Next request overwrites previous one

58
Power-Friendly

• Session 3

59
GRACE-OS

• Wanghong Yuan
• SOSP 2003

60
Motivation

• Mobile devices run on battery
• How to save battery?

61
Dynamic Voltage Scaling

• Example AMD Athlon 4 PowerOn 300, 500, 600,
  700, 800, 1000MHz
• Energy ? V2

62
CPU Scheduler

• When to execute a task
• How long to execute it
• How fast to execute it

63
CPU Reservation

• I need C units of time, out of every T units.

64
Probability Distribution
Cum. Prob.
cycles
65
CPU Requirements

• I need C units of time, out of every T units.

66
Speed Schedule
speed
time
67
Finding Speed Schedule

• Let task execute at speed vx during cycle x
• execution time
• power
• average power

68
Optimize This

• Minimize
• Subjected to

69
Implementation

• Linux Kernel
• AMD Athlon 4
• 716 lines of code

70
Findings

• Probability distribution is quite stable
• Able to meet deadlines with bounded miss ratio
• Save energy by 7 72

71
Proxy Assisted Streaming

• Prashant Shenoy et. al.
• MMCN 2003

72
Motivation

• Power-aware streaming to mobile device
• save energy in decoding frames
• save energy in receiving packets

73
Architecture
Heres my energy budget for decoding network
reception and max resolution
server/proxy
client
74
Architecture
OK, what should I send?
server/proxy
client
75
Information Needed

• Map stream properties to energy requirement
• Need to know decoding time of a frame

76
Frame Decoding Time
77
Estimating Frame Decoding Time
78
Transcoding

• If current stream would exceed client decoding
  energy budget
• Need to transcode by reducing quality

79
Transcode to what?

• E estimated energy needed
• while E gt energy budget
• reduce quality by e
• E estimate energy needed

80
Transcoded Streams
server/proxy
client
81
Reducing NIC Energy

• NIC has two modes active/sleep
• Client can activate NIC only when packets are
  expected.

82
Burst Transmission
I will start transmitting at 101254.86 pm
83
Evaluations
Decoding Time
Frame Number
84
Evaluations

• NIC Idle Uptime 2 20