Implementation of Proxy/Buffering Strategies in

Mpeg transmission for intermittent connectivity

CS218Samarth Pal, Ujjwal Lahoti, Xiaoyong Su

Tutor: Dr Manthos Kazantzidis

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

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

The Need for Buffering Capabilities

The Need for BufferingCapabilities

Network Loss Detected

Start Buffering

The Need for Buffering Capabilities

Re-Establish Connection

Option For1. Buffered Video2. Live Video

Different Strategies

• Buffering At Intermediate Nodes

Buffering IntermediateNode

Different Strategies

• Buffering At End Nodes

Buffering End Node

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

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

How the Buffering Works?

Live Video Buffering Live VideoBuffered Video

Connection Loss

Detected

ConnectedAgain

The Player has option of looking at the buffered

video or live video

System Architecture

Video Streaming

Server Client

Streaming ServerMPEG4, H261

RTP, RTSPPlay Back

Network Detecting

User controlControl Unit Raw Socket

ICMP

System Architecture

Video Streaming

Server Client

Streaming ServerMPEG4, H261

RTP, RTSPPlay Back

Network Detecting

User controlControl Unit Raw Socket

ICMP

Server States Switching

Buffer Off

Buffer On

Network On

Network OffTransmit Live

Transmit Buffer

BufferRequest

LiveRequest

Video Capture

Video Streaming

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

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 )

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}.

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

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

DEMO

The Player: GMP4PLAYER(Client)

The Streaming Program: MPEG4IP(Server)