1. Packetizing scalable streams in heterogeneous peer-to-peer networks Sentinelli, A. Kumar, T. Anselmo, B. Rossi, L. Fragneto STMicroelectronics Advanced System Technology (AST) Agrate Brianza (MB), Italy ICME 2011Barcelona

2. AGENDA Introduction Industrial Scenario The idea in a nutshell Background SVCand P2P together P2P Next Splitter Issues P2P-Next solution (propose solution) Adaptive Splitter Experiments and results Conclusions

3. Scenario: delivery to different networks The Internet IPTV Set-Top Box Media Server Same Scalable Video SVC can offer easy adaptation to: Desired QoS Bandwidth conditions Terminal capabilities Just “cut” portionsof the stream (No additionalcost) Hierarchicalcoding (Just take the layersthat I need) Onecontentstreamat server side (lessstorage)

4. Background: P2P-Next project 101010100010110110010 Application Layer: Layered Video Coding(SVC, MDC, others…) Network Layer : P2P (File-Sharing, Streaming) Networkscalability Videoqualityscalability GOAL: To combine P2Pand Layered Video Coding

5. 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 Wecompare twotypesof packetization methods

6. Interface between the P2P and the Layered Video Coding engine The server delivers two different streams independently encodedStream S1 = Low QualityStream S2 = High Quality The server delivers two layers (Base + Enhancement):Stream S1 = Base LayerStream S2 = Base + Enh Layer Base Layer Enh Layer S1 Base + Enh Layer S2 S1 Main server S2 Main server Background: P2P - synergy with SVC OLD: Overlays can NOT cooperate NEW: Overlays able to cooperate NAT and P2P v.1

9. From NALU toBlocks: framesskipped 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 BL CHUNK BL CHUNK BL CHUNK BL NALU BL NALU BL NALU BL NALU BL NALU BL NALU BL NALU BL NALU EL1 CHUNK EL1 CHUNK EL1 CHUNK EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL1 NALU EL2 CHUNK EL2 CHUNK EL2 CHUNK EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU EL2 NALU Video Encoder Input Pictures RAP PictureNALUs Non-RAP PictureNALUs Encapsulation Peer-to-Peer Engine LAYERS MUST BE KEPT SYNCHRONIZED All Blocks must have the same number of frames When a NALU doesn't fit into the block it is simply dropped

10. P2P-Next Splitter: packetization trade -off Oneblock per IDR, withNfr (Number of Frames per block) What is the best [Bs, Nfr] ? (Bs : Block size) (trade off)Keep all framesvsLess Overhead %frame skipped BlockSize Num Frames 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

11. P2P-Next Splittervs AdaptiveSplitter 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

12. Adaptive Splitter: Adaptive blocks Mapping EL 2,1 block EL 2,2 block EL 2,3 block EL 2,4 block EL1,1 block EL 1,2 block EL 1,3 block BL 0,1 block BL 0,2 block (...) (2,3,4) BL 0,1 BL 0,2 EL1,1 EL 1,2 EL 1,3 EL 2,1 EL 2,2 EL 2,3 EL 2,4 (2,2,2) BL 0,1 BL 0,2 EL1,1 EL 1,2 EL 2,1 EL 2,2 Quality Block Mask IDRi #blocks EL2 #blocks EL1 #blocks BL time Final Stream IDRi IDRi+1 Headers to identify the blocks Mask (blocks per IDR per Layer ) #blocks per IDR isdependentbyeach IDR size “So…whynotchoosing a block ofone 1 byte?” Toomuchsignalingoverhead… Becauseof the backwardcompatibility: (BitTorrent) MIN size=16kB

13. Experiments and results Theoreticalmodel: When the overhead decreases, the IDR size gets close to a multiple of Bs

14. Experiments and results The best Bs isnotalways the smallestone: MyBs

15. 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

16. 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 Splitterdoesn’t require a priori knowledge of block size to preserve all frames: good candidate for live streaming scenario

17. THANK YOU !

18. 18 Packetizing: overhead Fromrawstreamto 4 SVC encodedlayerswithbitrateB(*) and the mask (1, 1, 1, 3).  ie. the 4° layeris 4B (*) For rate control reasons, each file may have NALU with nal_unit_type = 12. These are Filler Data NALU, required by some application to get a precise { #Bytes/Chunk } and finally discarded by decoder. Overhead