A. Sentinelli, A. Kumar, T. Anselmo, B. Rossi, L. Fragneto

• STMicroelectronics • Advanced System Technology (AST)• Agrate Brianza (MB), Italy

PACKETIZING SCALABLE STREAMS IN HETEROGENEOUS PEER-TO-PEER NETWORKS

ICME 2011 Barcelona

AGENDA

• Introduction– Industrial Scenario– The idea in a nutshell

• Background– SVC and P2P together– P2P Next

• Splitter– Issues – P2P-Next solution– (propose solution) Adaptive Splitter

• Experiments and results• Conclusions

The Internet

Scenario: delivery to different networks

SVC can offer easy adaptation to:– Desired QoS

– Bandwidth conditions

– Terminal capabilities

SameScalable Video

MediaServer

IPTV Set-Top Box

Just “cut” portions of the stream (No additional cost)Hierarchical coding (Just take the layers that I need)One content stream at server side (less storage)

Background: P2P-Next project

Network Layer : P2P (File-Sharing, Streaming)

Application Layer: Layered Video Coding (SVC, MDC, others…)

GOAL:

To combine P2P and Layered Video Coding

Network scalability Video quality scalability

The idea in a nutshell

• P2P-Next EU project. Integration’s challenge :– Big picture view;– Interface designs among modules/layers/protocols;– Backward compatibility;

High chance of bottleneck or general loss of efficiency (overhead)

We found a strong lack of performance in the module that packetizes the Video stream into a P2P packet

We compare two types of packetization methods

Background: P2P - synergy with SVC

S2

S1

Main server

The server delivers two different streams independently encodedStream S1 = Low QualityStream S2 = High Quality

OLD: Overlays can NOT cooperate

The server delivers two layers (Base + Enhancement):Stream S1 = Base LayerStream S2 = Base + Enh Layer

Base LayerEnh LayerBase + Enh Layer S2

S1

Main server

NEW: Overlays able to cooperate

Interface between the P2P and the Layered Video Coding engine

Background: P2P – Next, full system

We focused

\

We found a “problem”

• Backward compatibility with P2P systems• IDR synchronization among NALU of different layers

8

From NALU to Blocks: overhead

• The Splitter parses and puts NALUs to respective layers

• Re-encapsulates the stream into Blocks for the P2P engine

CONSTRAINT: backward compatibility with torrent-like system

• ALL blocks must have the same size ( NALU type 12 *)

*(stuffing bits)

Overhead

From NALU to Blocks: frames skipped

Video Encoder

BL NALU BL NALU BL NALU BL NALU BL NALU BL NALU BL NALU

EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU

EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU

InputPictures

Peer-to-PeerEngine

BL NALU BL NALU BL NALU BL NALU BL NALU BL NALU BL NALU BL NALU

BL CHUNK BL CHUNK BL CHUNK

EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU

EL1 CHUNK EL1 CHUNK EL1 CHUNK

EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU

EL2 CHUNK EL2 CHUNK EL2 CHUNK

RAP PictureNALUs

Non-RAP PictureNALUs

Encapsulation

When a NALU doesn't fit into the block it is simply dropped

LAYERS MUST BE KEPT SYNCHRONIZED

All Blocks must have the same number of frames

P2P-Next Splitter: packetization trade -off

• What is the best [Bs, Nfr] ? (Bs : Block size)

(trade off) Keep all frames vs Less Overhead

BlockSize Num Frames

%frame skipped

On avg, given a bitrate B, the optimal trade off is when : Bs =Nfr· AvgFrB

AvgFrB : average size of a Frame given a bitrate B

One block per IDR, with Nfr (Number of Frames per block)

P2P-Next Splitter vs Adaptive Splitter

• P2P-Next approach: a unique block to embrace an IDR period

• Adaptive Splitter: many smaller (same size) blocks to cover until needed an IDR period (a black scene has less information than a panorama)

The Adaptive Splitter never discards frames

Adaptive Splitter: Adaptive blocks Mapping

Final Stream

#blocks EL2

#blocks EL1

#blocks BL

2

3

4

BL 0,1 block BL 0,2 block

EL1,1 block EL 1,2 block EL 1,3 block

EL 2,1 block EL 2,2 block EL 2,3 block EL 2,4 block

Block Mask IDRi

Headers to identify the blocks Mask (blocks per IDR per Layer )

(2,3,4) BL 0,1 BL 0,2EL1,1 EL 1,2 EL 1,3EL 2,1 EL 2,2 EL 2,3 EL 2,4 (2,2,2) BL 0,1 BL 0,2EL1,1 EL 1,2EL 2,1 EL 2,2 (...)

time

Quality

IDRi IDRi+1

#blocks per IDR is dependent by each IDR size

“So… why not choosing a block of one 1 byte?”

1. Too much signaling overhead…2. Because of the backward compatibility: (BitTorrent) MIN size=16kB

Experiments and results

• Theoretical model:

100%Bsize/B IDRTarget

Bmod size IDRTarget B O

sshead

ss

0

20

40

60

80

100

120

Block size (kB)

% Theoretical OVH L0 L1 L2

% Theoretical OVH L3

0

20

40

60

80

100

120

Block size (kB)

% OVH L0 L1 L2 (AVG)% OVH L3

When the overhead decreases, the IDR size gets close to a multiple of Bs

Experiments and results

• The best Bs is not always the smallest one:

0

20

40

60

80

100

120

Block size (kB)

%AVG OVH L0 L1 L2 L3

My Bs

Experiments and results

• Experiments on 6 sequences (5 short ones + 1 HD)

• On the whole, the adaptive approach gives up to:– ≈77% decrease in overhead, – ≈16% less of bandwidth

MinSize [kB]

OH [%]

Range [kB]

Min OH [%]

Avg Min OH [%]

City 30 119 19% [16-119] 5.4 13.5 71 11.4

Crew 30 132 29% [16-132] 6.5 15 77 17.4

Soccer 30 126 26% [16-126] 6.3 14.3 67 15.6

Tree 25 165 30% [16-165] 5.7 13.6 81 18.6

Flight 25 138 14% [16-138] 4 8.5 77 11.9

Home 24 240 38% [16-240] 5.7 13.1 85 23

Gained OH [%]

Gained BW [%]

Sequences frmR [fr/s]P2P Next Splitter Adaptive Splitter

Conclusions

• We have described the architecture of a P2P-SVC solution and the issues that overcome during the integration

• Performance comparison in terms of overhead of between the P2P-Next and the Adaptive Splitter

• Results show a remarkable gain (16% bandwidth), confirmed by our mathematical model

• The Adaptive Splitter doesn’t require a priori knowledge of block size to preserve all frames: good candidate for live streaming scenario

THANK YOU !