Title: Benefits of re-packetization for FEC based protection of multimedia streams
1Benefits 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
2Source 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
3Re-packetization
Sender
Receiver
Application producer
Application consumer
FEC block
FEC block
Packet restoral
Re- packetization
Internet
Header
4Proposed 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
5Assumptions 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)
6Alpha 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
-------------------------------------------------
-------------
7Results 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
8Feedback 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.