1 / 15

MPEG-TFRCP: Video Transfer with TCP-friendly Rate Control Protocol

MPEG-TFRCP: Video Transfer with TCP-friendly Rate Control Protocol. Department of Informatics and Mathematical Science, Graduate School of Engineering Science, Osaka University, Japan Masaki Miyabayashi E-mail: miyabays@ics.es.osaka-u.ac.jp. Use of multimedia apps. increases. Introduction.

dore
Télécharger la présentation

MPEG-TFRCP: Video Transfer with TCP-friendly Rate Control Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MPEG-TFRCP: Video Transfer with TCP-friendly Rate Control Protocol Department of Informatics and Mathematical Science, Graduate School of Engineering Science, Osaka University, Japan Masaki Miyabayashi E-mail: miyabays@ics.es.osaka-u.ac.jp ICC2001

  2. Use of multimedia apps. increases Introduction • Unfairness: TCP vs.UDP • TCP: traditional data applications • Congestion control • UDP: real-time multimedia applications • No control mechanisms TCP，UDP co-exist 10 UDP 9 TCP 8 7 6 Rate [Mbps] 5 4 3 “Greedy” UDP degrades TCP performance 2 1 0 0 10 20 30 40 50 60 Time [sec]

  3. TCP-friendly rate control “A non-TCP connection should receive the same share of bandwidth as a TCP connection if they traverse the same path.” • TFRCP (TCP-friendly Rate Control Protocol) • Equation-based control • Estimate TCP throughput • AIMD control (Additive Increase/Multiplicative Decrease) ICC2001

  4. and r i I - i 2 r - i 2 r = r + 2 i 1 i MTU = r + i 1 2 p 3 p 2 + + RTT min( 1 , 3 ) p ( 1 32 ) p T 0 3 8 MPEG-TFRCP mechanisms Lossestimation determine I i control interval I I I + - 1 i i 1 i sending rate r r r sender + - i 1 i 1 i • Estimate network condition from feedback information • Derive TCP throughput • Regulate the sending rate time lost lost receiver • Estimation of RTT, Loss • how to get feedback information? • applicability for real system? • No loss, • Loss, • perceived video quality? • adjusting MPEG-2 video rate Ref [10]： Naoki Wakamiya, Masayuki Murata, and Hideo Miyahara, “On TCP-friendly video transfer,” in Proceedings of SPIE International Symposium on Information Technologies 2000, November 2000.

  5. Research Targets • Demonstrate applicability of MPEG-TFRCP to real system • Perceived video quality at receiver • MOS (Mean Opinion Score) • Observation of traffic on the link • Average throughput • Rate variation • Improve MPEG-TFRCP • Rate control algorithm • Control interval ICC2001

  6. System configuration TCP TFRCP/UDP Senders Receivers ICC2001

  7. Trans- mitter Quantizer Receiver Sender QoS Hard Manager Report Report Scale Disk MPEG-TFRCP sender & receiver Sender-side Receiver-side Camera Encoder Monitor video data RTP RTP Decoder Receiver UDP UDP target rate Estimator RTCP RTCP ICC2001

  8. 10 25 1 loss MPEG-TFRCP target rate TCP video rate 8 20 6 15 packet loss probability Rate [Mbps] Rate [Mbps] 0.1 4 10 2 5 0 0 0.01 0 50 100 150 200 0 50 100 150 200 GoP times = 1.001 sec GoP times Original MPEG-TFRCP Drastic rate variation • Increasing exponentially, decreasing extremely Average throughput： TCP 4.4 [Mbps]，TFRCP 2.0 [Mbps] • Not TCP-friendly Lower subjective video quality: MOS 1.25 ICC2001

  9. Rate 20 15 Average rate [Mbps] 10 MTU = r + i 1 2 p 3 p 2 + + RTT min( 1 , 3 ) p ( 1 32 ) p T 5 0 3 8 0 0 10 20 30 40 50 60 Quantizer scale Improving rate control algorithm • Quantizer-scale-based Additive Increase algorithm (QAI) • When no loss occurs, • Increase sending rate with regard to quantizer scale Decrease quantizer scale by two Initially set at 60 • When loss occurs, • Original algorithm

  10. 10 TCP MPEG-TFRCP 8 6 Rate [Mbps] 4 2 0 0 50 100 150 200 GoP times Evaluation of QAI MPEG-TFRCP Rate variation becomes relatively smaller Not TCP-friendly • TCP : 4.3 [Mbps] • TFRCP : 2.3 [Mbps] Not attain high-quality video transfer (MOS) • UDP : 4.25 • Original : 1.25 • QAI : 2.50 Rate variation (QAI) ICC2001

  11. Variants in packet loss probability derivation • Original • React so quickly against short-term congestion Extreme rate fluctuation • Cumulative packet Loss probability (CL) Number of Lost packets , within each control interval Loss = Number of transmitted packets Total number of Lost packets Loss = Total number of transmitted packets , from beginning of the session ICC2001

  12. 10 0.1 loss TCP MPEG-TFRCP 8 0.01 6 packet loss probability Rate [Mbps] 4 0.001 2 0 0 50 100 150 200 GoP times Evaluation of QAI-CL Rate and packet loss probability variations (QAI-CL) Rate variation becomes relatively small Improve video quality • Original : 1.25 • QAI : 2.50 • QAI-CL : 3.00 accomplish reasonable TCP-friendly control • TCP : 3.7 [Mbps] • QAI-CL : 3.0 [Mbps] ICC2001

  13. Election of the control interval • When interval is too short, • Perceived video quality becomes unstable • Cannot estimate network condition precisely • When interval is too long, • Cannot follow changes of network condition 32-RTT: proposal é ù 32 RTT = Interval GoPtime 8-RTT: ê ú GoPtime ê ú shorter 16-RTT: 64-RTT: longer 96-RTT: ICC2001

  14. 16-RTT or 32-RTT control interval is appropriate Several settings of control interval Throughput [Mbps] MOS value Friendliness TFRCP TCP 8-RTT 3.10 3.53 0.878 2.25 16-RTT 2.87 3.71 0.774 3.25 32-RTT 2.97 3.70 0.802 3.00 64-RTT 2.51 4.06 0.618 3.33 96-RTT 2.33 4.29 0.543 2.50 ICC2001

  15. Conclusion • Conclusions • Evaluated applicability of proposed method to real system • Improving the TCP-friendliness and perceived video quality by our method (QAI-CL MPEG-TFRCP) • Future work • Larger scale network • Consider RTT variation ICC2001

More Related