46
F.LIV E Shannon Chen ([email protected]), Zhenhuan Gao, and Klara Nahrstedt University of Illinois at Urbana-Champaign Towards Interactive Live Broadcast Free-viewpoint TV Experience This material is based in part upon work supported by the National Science Foundation (NeTS-0520182)

f.live

Embed Size (px)

Citation preview

Page 1: f.live

F.LIVEShannon Chen ([email protected]),

Zhenhuan Gao, and Klara NahrstedtUniversity of Illinois at Urbana-Champaign

Towards Interactive Live Broadcast Free-viewpoint TV Experience

This material is based in part upon work supported by the National Science Foundation (NeTS-0520182)

Page 2: f.live

FREE-VIEWPOINT TV (FTV)

Multi-Lens Capturing

Free-Viewpoint Viewing

Page 3: f.live

DESIRED FTV FEATURES• Interactive• Live• Broadcasting

Page 4: f.live

DESIRED FTV FEATURES• Interactive

• Live• Broadcasting

*beep*

Page 5: f.live

DESIRED FTV FEATURES• Interactive

• Live• Broadcasting

Page 6: f.live

DESIRED FTV FEATURES• Interactive• Live

• Broadcasting

Page 7: f.live

DESIRED FTV FEATURES• Interactive• Live

• Broadcasting

Page 8: f.live

DESIRED FTV FEATURES• Interactive• Live• Broadcasting

1000-scale audience group

Page 9: f.live

EXISTING FTV DELIVERY

FRAMEWORKS• Type-1: View chosen by content provider• EyeVision System [Kanade ‘01] used in Super Bowl

XXXV

Editing DecodeAggregateCapture

Capture

Capture

Encode

Director

Viewpoint decision

Audience

• Interactive• Live

Page 10: f.live

EXISTING FTV DELIVERY

FRAMEWORKS• Type-2: Aggregated stream bundle• Nagoya System [Tanimoto ‘12]

• Interactive• Live

DecodeAggregateCapture

Audience

CaptureViewpoint decision

Capture

Encode

Page 11: f.live

OUR SOLUTION: F.LIVE• View-based delivery framework

Audience 1

Viewpoint decisions

Renderer

Audience 2

Renderer

Decode

Decode

Capture

Capture

Capture

Encode Transmit

Transmit

TransmitEncode

Encode

Session manager

Transmission assignment

• Interactive• Live • Broadcasting ?

Page 12: f.live

OUR SOLUTION: F.LIVE• No aggregation → distributed entities• P2P sharing among audience• Pub/Sub Model

Session manager

Page 13: f.live

OUR SOLUTION: F.LIVE• No aggregation → distributed entities• P2P sharing among audience• Pub/Sub Model

Session manager

Publishers

Page 14: f.live

OUR SOLUTION: F.LIVE• No aggregation → distributed entities• P2P sharing among audience• Pub/Sub Model

Session manager

Broker

Page 15: f.live

OUR SOLUTION: F.LIVE• No aggregation → distributed entities• P2P sharing among audience• Pub/Sub Model

Session manager

Subscribers

Page 16: f.live

OUR SOLUTION: F.LIVE

Session manager

View decisions

Page 17: f.live

OUR SOLUTION: F.LIVE

Session manager

Transmission assignments

Page 18: f.live

OUR SOLUTION: F.LIVE

Session manager

Page 19: f.live

OUR SOLUTION: F.LIVE• No aggregation → distributed entities• P2P sharing among audience• Pub/Sub Model

S

SS

Physical proximity

• Broadcasting

Page 20: f.live

CHALLENGES• Interactive ← Synchronization delay• Live ← Content freshness• Broadcast ← Producer bandwidth

Page 21: f.live

CHALLENGES

R

Page 22: f.live

CHALLENGES• Synchronization delay• Content freshness

Buffer for stream A

Buffer for stream BCam

B

Cam A

Audience site

1

1

Page 23: f.live

CHALLENGES• Synchronization delay• Content freshness

Buffer for stream A

Buffer for stream BCam

B

Cam A

Audience site

1

2

2

1

Page 24: f.live

CHALLENGES• Synchronization delay• Content freshness

Buffer for stream A

Buffer for stream BCam

B

Cam A

Audience site

1

12

3

3

2

Wait

Page 25: f.live

CHALLENGES• Synchronization delay• Content freshness

Buffer for stream A

Buffer for stream BCam

B

Cam A

Audience site

1

12

2

3

4

4

3

Page 26: f.live

CHALLENGES• Synchronization delay• Content freshness

Buffer for stream A

Buffer for stream BCam

B

Cam A

Audience site

1

12

2

3

4

4

3

Rendering

Page 27: f.live

CHALLENGES• Synchronization delay• Content freshness

Buffer for stream A

Buffer for stream BCam

B

Cam A

Audience site

1

12

2

3

4

4

3

Rendering

Propagation delay (i.e., frame elapse = freshness)

Synchronization delay

Page 28: f.live

CHALLENGES• Synchronization delay• Content freshness• Producer Bandwidth

Page 29: f.live

CHALLENGES• Synchronization delay• Content freshness• Producer Bandwidth

Page 30: f.live

CHALLENGES• Synchronization delay• Content freshness• Producer Bandwidth

Gbps

Page 31: f.live

FOREST PLANNING CHALLENGES

• If we have all the subscription information at the beginning of forest planning , an optimal planning is not a hard problem

• However, subscriptions are dynamic• P2P churn• View change “Forest

adaptation”Initial forest construction

Cam B

Cam A

Cam C

Page 32: f.live

FOREST PLANNING CHALLENGES

• If we have all the subscription information at the beginning of forest planning , an optimal planning is not a hard problem

• However, subscriptions are dynamic• P2P churn• View change “Forest

adaptation”Initial forest construction

Cam B

Cam A

Cam C

Audience join

Bandwidth?Freshness?

Page 33: f.live

FOREST PLANNING CHALLENGES

• If we have all the subscription information at the beginning of forest planning , an optimal planning is not a hard problem

• However, subscriptions are dynamic• P2P churn• View change “Forest

adaptation”Initial forest construction

Cam B

Cam A

Cam C

Audience leave

Page 34: f.live

FOREST PLANNING CHALLENGES

• If we have all the subscription information at the beginning of forest planning , an optimal planning is not a hard problem

• However, subscriptions are dynamic• P2P churn• View change “Forest

adaptation”Initial forest construction

Cam B

Cam A

Cam C

Audience leave

3 4

Page 35: f.live

FOREST PLANNING CHALLENGES

• If we have all the subscription information at the beginning of forest planning , an optimal planning is not a hard problem

• However, subscriptions are dynamic• P2P churn• View change “Forest

adaptation”Initial forest construction

Cam B

Cam A

Cam C

View change

Page 36: f.live

FOREST PLANNING CHALLENGES

• If we have all the subscription information at the beginning of forest planning , an optimal planning is not a hard problem

• However, subscriptions are dynamic• P2P churn• View change “Forest

adaptation”Initial forest construction

Cam B

Cam A

Cam C

View change 3 3

Page 37: f.live

FOREST PLANNING CHALLENGES

• If we have all the subscription information at the beginning of forest planning , an optimal planning is not a hard problem

• However, subscriptions are dynamic• P2P churn• View change

We do not aim for optimization (no tearing down trees) Heuristics that deal with new batch of subscription

requests (audience join/leave/view change) Details on initial construction and adaptation

algorithms (w/ pseudocodes) can be found in the paper [Shannon Chen et al. INFOCOM’16]

“Forest adaptation”

Initial forest construction

Page 38: f.live

EVALUATION• Simulation settings

• Single TV-studio performer site

• Network capability of audience sites: [Netmap]• In/out-bound bandwidth, site-to-site propagation delay

• Simulate new subscription requests when there are 0 to 100,000 audiences in the session

High-resolution cameras

Moderate 100-camera array

# of cameras 16 30 100Camera framerate 30 FPS 30 FPS 30 FPSCamera bitrate 12 Mbps (HDTV) 6 Mbps 2 Mbps (SDTV)

Page 39: f.live

EVALUATION METRICS• Synchronization delay (Interactive)• Content freshness (Live)• Producer bandwidth (Broadcast)

Page 40: f.live

SYNCHRONIZATION DELAY

• Unstable at first: not many candidates for newly joined/rejoined audience to find a group of sources with similar propagation delays

• Delay for handling new coming subscriptions during application session is in 100ms-scale in stable state

020

040

060

080

010

000

200400600800

1000High-Res Setting

Audience group size0

200

400

600

800

1000

0200400600800

1000Moderate Setting

Audience group size0 5000 100000

200400600800

1000100-Camera Setting

Audience group size

Sync

del

ay

(ms)

Sync

del

ay

(ms)

Sync

del

ay

(ms)

Page 41: f.live

PRODUCER BANDWIDTH

CONSUMPTION

• P2P sharing restricts the growth of bandwidth consumption

• Outbound bandwidth requirement is well-manageable by Gbps infrastructure

0 200 400 600 80010000

250

500High Bitrate Setting

Audience group size

Tota

l pro

duce

r bi

trate

(Mbp

s)

0 200 400 600 80010000

250

500Moderate Setting

Audience group size

Tota

l pro

duce

r bi

trate

(Mbp

s)0 2500 50000

250

500100-Camera Setting

Audience group size

Tota

l pro

duce

r bi

trate

(Mbp

s)

Page 42: f.live

CONTENT FRESHNESS

• > 50% audience have higher-than-average elapses

• But the tree structure makes the elapse grows sub-linearly• Max elapse < 4.5 seconds

(compare: CBS TV network’s time elapse is 5 sec)

Page 43: f.live

COMPARE TO OTHER FTV FRAMEWORKS

Editing DecodeAggregateCap

Cap

Cap

Encode

Audience

DecodeAggregateCap

Audience

CapViewpoint decision

Cap

Encode

Type-1: customized content

Type-2: aggregated content

Viewpoint decision

MVC

Page 44: f.live

COMPARE TO OTHER FTV FRAMEWORKS

020406080

100120140160

Band

widt

h co

nsum

ptio

n of

aud

ienc

e sit

e (M

pbs)

High-Res Moderate 100-CamerasType-1 (dash)View-based (solid)

High-Res Moderate 100-CamerasType-2 (stripe); View-based (solid)

Producer site bandwidth consumption

Audience site bandwidth consumption

Page 45: f.live

CONCLUSION• We propose a new FTV content delivery framework

which aims at co-existence of three desired features• Interactive• Live• Broadcasting

• Result of large-scale simulation shows the proposed F.Live framework with view-based delivery chain achieves• Interactive response time in 100ms-scale• Acceptable content freshness by TV industry standard• Feasible bandwidth consumption while sustaining

1000-scale audience group

Page 46: f.live

THANK YOU