Benefits of re-packetization for FEC based protection of multimedia streams - PowerPoint PPT Presentation

About This Presentation
Title:

Benefits of re-packetization for FEC based protection of multimedia streams

Description:

Benefits of re-packetization for FEC based protection of multimedia streams Authors: Pierre Roux Christophe Janneteau Mounir Kellil CEA LIST 77th IETF Meeting – PowerPoint PPT presentation

Number of Views:65
Avg rating:3.0/5.0
Slides: 9
Provided by: Pier2188
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: Benefits of re-packetization for FEC based protection of multimedia streams


1
Benefits of re-packetization for FEC based
protection of multimedia streams
  • Authors
  • Pierre Roux
  • Christophe Janneteau
  • Mounir Kellil
  • CEA LIST

77th IETF Meeting Anaheim, CA, USA
2
Source packets either sent transparently, or
re-packetized
  • What if no requirement for compatibility with
    legacy applications (non FEC aware) ?
  • Would re-packetization of source packets be
    useful?
  • If yes, evaluate the benefit.
  • Proposed re-packetization
  • Equalize source packet sizes within each FEC
    source block in the sender.
  • Restore original packets with variable sizes in
    the receiver.
  • Motivation
  • 1 packet 1 symbol
  • 1 lost source packet 1 lost source symbol
    only.
  • To be used outside of FECFRAME and combined with
    it

Source packets
Re- packetization
FEC Framework (Tx)
FEC Framework (Rx)
Packet restoral
Application producer
Application consumer
FEC packets
3
Re-packetization
Sender
Receiver
Application producer
Application consumer
FEC block
FEC block
Packet restoral
Re- packetization
Internet
Header
4
Proposed header for re-packetization
Block index
First byte
Packet index
Second byte
Size of the original packet corresponding to
the above index
Third fourth bytes




5
Assumptions for simulations
  • Compare 2 approaches
  • Approach 1 without re-packetization.
  • Approach 2 with re-packetization.
  • Use real sample media stream (H264 AVC, 119.9
    kbit/s)
  • Block periodicity 500 ms
  • All compared configurations must have equal total
    bit-rate (source bit-rate FEC bit-rate). All
    headers are taken into accounts for bit-rate
    calculation.
  • Common design rules
  • Maximum Distance Separable codes are used.
  • Design rules for approach 2
  • 1 symbol per packet.
  • Add as many FEC packets as there are source
    packets.
  • Also take into account the effect of packet
    losses on the process of original packet restoral
    in the receiver.
  • Total bitrate 253.1 kbit/s
  • Design rules for approach 1
  • Consider several possible symbol lengths
    (16,32,64,128,512,1024)
  • Consider several possible number of FEC symbols
    per FEC packet (1,2,5,10,20)
  • Adjust the number of FEC symbols in order to
    reach the same total bitrate as for approach 2
    (alpha adjustment factor)

6
Alpha values for approach 1
----------------------------------------------
---------------- Symbol Number of repair
symbols per repair packet size

1 2 5
10 20

16 0.336 0.508 0.734 0.862
0.944 32 0.502 0.675
0.851 0.932 0.979 64
0.661 0.798 0.912 0.958 0.982
128 0.766 0.854 0.919
0.941 XXXXX 256 0.789
0.834 0.867 XXXXX XXXXX
512 0.723 0.750 XXXXX XXXXX
XXXXX 1024 0.539 XXXXX
XXXXX XXXXX XXXXX
-------------------------------------------------
-------------
7
Results with Packet Loss Ratio 0.2
-------------------------------------------------
----------------- Symbol Number of
repaired symbol per repaired packet
size
1 2
5 10 20

16 8.85x10-2 2.24x10-2
1.59x10-3 3.86x10-4 3.7x10-4 32
2.37x10-2 3.32x10-3 4.24x10-4 3.89x10-4
1.04x10-3 64 3.86x10-3 7.13x10-4
4.30x10-4 1.06x10-3 3.32x10-3 128
1.03x10-3 5.13x10-4 1.19x10-3 3.47x10-3
XXXXXXXXX 256 1.08x10-3 1.34x10-3
4.19x10-3 XXXXXXXXX XXXXXXXXX 512
2.87x10-3 4.12x10-3 XXXXXXXXX XXXXXXXXX
XXXXXXXXX 1024 1.87x10-2 XXXXXXXXX
XXXXXXXXX XXXXXXXXX XXXXXXXXX
------------------------------------------------
------------------
Approach 1 with best config residual
PLR3.7x10-4 Approach 2 residual PLR1.5x10-4
8
Feedback from FECFRAME list
  • From Thomas Stockhammer
  • Backward compatibility issue.
  • Acknowledged.
  • Consider use of RFC3984.
  • Noted for possible study. However it would not be
    a generic solution.
  • Clarification that  short symbol many symbols
    per repair packets  is not a pitfall.
  • Acknowledged. Some results in Figure 4 (PLR0.1)
    are not consistent in this respect. Results for
    PLR0.1 will be repeated with longer simulation
    times.
  • From Einat Yellin
  • Backward compatibility issue.
  • Acknowledged.
  • Possible CPU issues.
  • To be investigated.
  • Simulation assumptions to be re-considered, e.g.
  • 500 ms for block periodicity may be too high for
    low latency applications.
  • Noted. Will be used for next simulations.
  • Use only a fraction of source bit-rate for FEC.
  • Noted. Will be used for next simulations.
  • Introduce lower PLR (e.g. 1-5 instead of 10 or
    20).
  • Noted. Will be used for next simulations.
Write a Comment
User Comments (0)
About PowerShow.com