1 / 20

Implementation of Proxy/Buffering Strategies in Mpeg transmission for intermittent connectivity

Implementation of Proxy/Buffering Strategies in Mpeg transmission for intermittent connectivity. CS218 Samarth Pal, Ujjwal Lahoti, Xiaoyong Su Tutor: Dr Manthos Kazantzidis. Presentation Outline. MPEG4IP Why we need buffering capabilities? Different Strategies for buffering

zuri
Download Presentation

Implementation of Proxy/Buffering Strategies in Mpeg transmission for intermittent connectivity

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. 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. The Need for BufferingCapabilities Network Loss Detected Start Buffering

  6. The Need for Buffering Capabilities Re-Establish Connection • Option For • Buffered Video • 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. Live Video Buffered Video How the Buffering Works? Connection Loss Detected Connected Again Live Video Buffering The Player has option of looking at the buffered video or live video

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

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

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

  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)

More Related