1 / 23

WiSE Video: using in-band wireless loss notification to improve rate-controlled video streaming

WiSE Video: using in-band wireless loss notification to improve rate-controlled video streaming . A. Markopoulou, E. Setton, M. Kalman, J. Apostolopoulos To appear in IEEE ICME 2004. Outline. WiSE Mechanism WiSE Video Simulation Results. Outline. WiSE Mechanism WiSE Video

aaralyn
Télécharger la présentation

WiSE Video: using in-band wireless loss notification to improve rate-controlled video streaming

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. WiSE Video:using in-band wireless loss notification to improve rate-controlled video streaming A. Markopoulou, E. Setton, M. Kalman, J. Apostolopoulos To appear in IEEE ICME 2004

  2. Outline • WiSE Mechanism • WiSE Video • Simulation Results

  3. Outline • WiSE Mechanism • WiSE Video • Simulation Results

  4. M-ECN • opportunistic signaling, using bits of the IP header that are lightly utilized • Capacity of ECN “channel” • Stengths: no overhead, no dedicated packet fields, incrementally deployable • Limitations: low rate, delay … M-ECN • Network to higher layers signaling needed • E.g. signal congestion, announce available BW etc… • Ways to signal: ICMP, dedicated bits, …

  5. wired wireless 1 2 3 WiSE: Wireless Signaling via ECN • TCP over wireless • Should not backoff in case of wireless loss • Wireless loss notification for TCP • Distinguish congestion from wireless losses • Avoid backing off in case of wireless loss • Many approaches [ELN, ETEN, …] • WiSE: • Use M-ECN to signal corruption vs. congestion • WiSE-Agent on router and WiSE-TCP to decode

  6. Outline • WiSE Mechanism • WiSE Video • Simulation Results

  7. … GOP … time I1 P2 P3 P12 P10 I11 Video Streaming • Characteristics: stream traffic, dependencies • Require: low loss and low delay • Rate-control • needed to react to congestion • rate-based vs. window-based

  8. Rate Control Schemes considered • HTTP streaming • One description stored, sent over TCP • [TCP friendly] • Compute TCP friendly rate • Adjust parameters (Q,fps) to meet it • E.g. [RAP: Reja et.al], [Zakhor et.al], … • Switch Stream (SSRC) • Receiver sends feedback • Sender switches (at GOP borders) to • lower rate during congestion • higher rate otherwise TCP friendliness Natural to Video

  9. Video over wireless • Problems in wireless • High values of loss and delay • High variability in loss and delay • Corruption can be misinterpreted as congestion • Solution: proxies, explicit messages • WiSE can help: • To distinguish congestion from corruption • In rate control: to avoid unnecessary decreases • In error resilience: to retransmit fast

  10. Outline • WiSE Mechanism • WiSE Video • Simulation Results • Topology • Streaming 1: SSRC • Streaming 2: HTTP

  11. Interfering traffic bottleneck WiSE Agent Wireless Link Video stream Video Source Playout buffer Video Rcvr n0 n1 n2 n3 n5 n4 Simulation Scenario • Topology • Links: wired (10Mbps, 10ms), wireless (1.1 Mbps, 100ms) • Congestion Loss: due to interfering traffic (FTP and HTTP) • Wireless Loss: model (bernoulli, bursty), rates 0-10%

  12. Video Streaming Details • Foreman sequence • 10sec, 30fps, QCIF, H.264, GOP=15 (1I:14P), UDP/RTP • Streams of various rates are pre-stored • Switching among streams • only allowed at GOP borders • dictated by rate control scheme

  13. SSRC Receiver If sequence gap, then send a NACK Sender If NACK received, then switch one stream lower Otherwise (and no NACK or increase recently), switch one stream higher WiSE SSRC Receiver If sequence gap, read WiSE message, send NACK + cause (congestion, corruption) Sender If congestion NACK, then switch one stream lower If corruption NACK, then retransmit + do not switch Otherwise (and no NACK or increase recently), switch one stream higher Rate Control 1: Switch Stream (SSRC)

  14. SSRC vs. WiSE SSRC- an example

  15. Quality metric: avg PSNR (dB) Demo (1) : SSRC vs. WiSE-SSRC • Scenario: No congestion, 4% bernoulli wireless loss • Improvement: better quality pictures, less freezes, 8dB

  16. SSRC vs. WiSE SSRC – Bernoulli Wireless Loss

  17. SSRC vs. WiSE SSRC- Bursty Wireless Loss

  18. wired wireless 1 2 3 SSRC vs. WiSE SSRC - all (wireless, wired) losses wireless loss % wireless loss % wired loss % wired loss % SSRC: 31..22dB WiSE-SSRC: 36 ..28dB

  19. TCP Receiver send ACKs Sender If congestion, then retransmit and half the window Otherwise (no congestion for some time), then increase WiSE TCP Receiver Send ACKs with echo set (WiSE marks) Sender If drop, then decode WiSE If congestion, then retransmit + half the window If corruption, then retransmit but do not half the window Otherwise (no congestion for sometime), then increase Rate Control 2: HTTP streaming • Video description #1 only. Viewed as a file to transfer • No notion of video-specifics, GOP, etc

  20. TCP vs. WiSE TCP - an example • Video description #1, 200sec • wireless loss: 0.6% bursty • congestion: interfering long FTPs

  21. TCP vs. WiSE TCP

  22. Demo (2): TCP vs. WiSE TCP • With congestion, 2% wireless loss • Improvement: (much) less freezes

  23. Conclusion • WiSE improves the quality of rate-controlled video over wireless, for a wide range of conditions • Further applications of network-to-application signaling ? • E.g. playout buffer, monitoring paths • Limitations • How much info? • How fast? (video: 30fps, WiSE: multiple packets for 1 bit, perceptible delays: ~150ms) • Compared to e2e?

More Related