1. Implementation of Proxy/Buffering Strategies in Mpeg transmission for intermittent connectivity CS218 Samarth Pal, Ujjwal Lahoti, Xiaoyong Su Tutor: Dr Manthos Kazantzidis

2. Presentation Outline MPEG4IP Why we need buffering capabilities? Different Strategies for buffering Changes we have added –How to buffer? –System Architecture –Network Detection Future Work DEMO

3. MPEG4-IP What is MPEG4-IP –Open Source, Open Standards, Open Streaming –Tool for streaming video and audio that is standards-oriented and free from proprietary protocols and extensions. –Unicast and Multicast Support –Recording Capabilities –Transmitting Pre-Recorded Video

4. The Need for Buffering Capabilities

5. Network Loss Detected Start Buffering

6. The Need for Buffering Capabilities Re-Establish Connection Option For 1.Buffered Video 2.Live Video

7. Different Strategies Buffering At Intermediate Nodes Buffering Intermediate Node

8. Different Strategies Buffering At End Nodes Buffering End Node

9. End To End vs. Intermediate End To End –Simple Implementation –More Reliable –Easier to control –More Latency –Highly Scalable –Support for high mobility in an ad-hoc environment Intermediate –Burden on every node to run the application –Unreliable because of mobility –Reduces Latency –Not Scalable –Complex Implementation

10. How We Implemented Buffering Queue based buffer Start buffering when connection with the player is lost Maximum buffer is adjustable –Current Value = 1 minute Client has capability of asking for full length buffer or for last ‘n’ seconds

11. How the Buffering Works? Live VideoBuffering Live Video Buffered Video Connection Loss Detected Connected Again The Player has option of looking at the buffered video or live video

12. System Architecture Video Streaming Server Client Streaming Server MPEG4, H261 RTP, RTSP Play Back Network Detecting User control Control Unit Raw Socket ICMP

13. System Architecture Video Streaming Server Client Streaming Server MPEG4, H261 RTP, RTSP Play Back Network Detecting User control Control Unit Raw Socket ICMP

14. Server States Switching Buffer Off Buffer On Network On Network Off Transmit Live Transmit Buffer Buffer Request Live Request Video Capture Video Streaming

15. Network Detecting Server pings the client every 1 second Time out indicates that the network connection might be broken. Calculate packet loss rate based on the moving window If the loss rate is larger than threshold, then send message to streaming thread to start buffering. Moving Window

16. Issues On Network Detection Moving window size (Current set to 2) Threshold (decided by window size, 50%) The time out setting (1s) Why not use estimated bandwidth by RTSP (using bandwidth as criteria will mess up the buffering, keep the functionality independent and simple )

17. Socket Control Design Client sends out the message. The Server only accepts the control message and reacts according to the message. It’s independent of the streaming thread. Control messages include the video type (buffered or live), if buffered video, then the Duration. Struct MESSAGE{ int nMsg, int nDuration}.

18. Performance Time taken to detect network outage: 1-2 seconds Time taken to detect that network is back online: ~1 second Time required to switch from buffered to live video (and vice versa): Realtime Live Video Latency: ~2 seconds Buffered Video is choppy

19. Future Work Support for longer buffers Enhancing the client: –Add gui-components that tell the client about server status and if buffered video is available –Capability to view live AND buffered video at once Better quality for buffered playback

20. DEMO The Player: GMP4PLAYER (Client) The Streaming Program: MPEG4IP (Server)