Presentation is loading. Please wait.

Presentation is loading. Please wait.

Draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d 2010 1 Benefits of re-packetization for FEC based protection of multimedia.

Similar presentations


Presentation on theme: "Draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d 2010 1 Benefits of re-packetization for FEC based protection of multimedia."— Presentation transcript:

1 draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d 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 draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d 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: Re- packetization FEC Framework (Tx) FEC Framework (Rx) Packet restoral Application producer Application consumer Source packets FEC packets

3 draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d Re-packetization FEC block Internet FEC block Application producer Re- packetization Packet restoral Application consumer SenderReceiver Header

4 draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d Proposed header for re- packetization Block index Packet index Size of the original packet corresponding to the above index First byte: Second byte: Third & fourth bytes:

5 draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d Assumptions for simulations Compare 2 approaches: –Approach 1: without re-packetization. –Approach 2: with re-packetization. Use real sample media stream (H264 AVC, 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 = 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 draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d Alpha values for approach | Symbol | Number of repair symbols per repair packet | | size: | | | | | | | | | 16 | | | 32 | | | 64 | | | 128 | XXXXX | | 256 | XXXXX XXXXX | | 512 | XXXXX XXXXX XXXXX | | 1024 | XXXXX XXXXX XXXXX XXXXX |

7 draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d Results with Packet Loss Ratio = | Symbol | Number of repaired symbol per repaired packet | | size: | | | | | | | | | 16 | 8.85x x x x x10-4 | | 32 | 2.37x x x x x10-3 | | 64 | 3.86x x x x x10-3 | | 128 | 1.03x x x x10-3 XXXXXXXXX | | 256 | 1.08x x x10-3 XXXXXXXXX XXXXXXXXX | | 512 | 2.87x x10-3 XXXXXXXXX XXXXXXXXX XXXXXXXXX | | 1024 | 1.87x10-2 XXXXXXXXX XXXXXXXXX XXXXXXXXX XXXXXXXXX | Approach 1 with best config: residual PLR=3.7x10 -4 Approach 2: residual PLR=1.5x10 -4

8 draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d 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 (PLR=0.1) are not consistent in this respect. Results for PLR=0.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.


Download ppt "Draft-roux-fecframe-repacketization-00..txt, CEA LIST, 77th IETF Meeting, March 23d 2010 1 Benefits of re-packetization for FEC based protection of multimedia."

Similar presentations


Ads by Google