• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Packetizing scalable streams in heterogeneous peer to-peer networks
 

Packetizing scalable streams in heterogeneous peer to-peer networks

on

  • 2,495 views

 

Statistics

Views

Total Views
2,495
Views on SlideShare
1,545
Embed Views
950

Actions

Likes
0
Downloads
11
Comments
0

2 Embeds 950

http://www.scoop.it 949
http://webcache.googleusercontent.com 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Packetizing scalable streams in heterogeneous peer to-peer networks Packetizing scalable streams in heterogeneous peer to-peer networks Presentation Transcript

    • 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
    • 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
    • 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)
    • 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
    • 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
    • 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
    • Background: P2P – Next, full system
      Wefound a “problem”
      We focused

      • Backward compatibility with P2P systems
      • IDR synchronization among NALU of different layers
    • 8
      From NALU toBlocks: overhead
      The Splitter parses and puts NALUs to respective layers
      Re-encapsulates the streamintoBlocksfor the P2P engine
      CONSTRAINT: backwardcompatibilitywithtorrent-likesystem
      ALL blocksmusthave the samesize ( NALU type 12 *)
      *(stuffingbits)
      Overhead
    • 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
    • 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
    • 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
    • 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
    • Experiments and results
      Theoreticalmodel:
      When the overhead decreases, the IDR size gets close to a multiple of Bs
    • Experiments and results
      The best Bs isnotalways the smallestone:
      MyBs
    • 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
    • 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
    • THANK YOU !
    • 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