EE 899: Multimedia Communications Project

Network Aware Video on Demand

Kay Sripanidkulchai

I Proposal

     Prof. Chen's comments on the proposal
 

II Midterm Project Report (Work in Progress)

Introduction

The technology for delivering ubiquitous high bandwidth multimedia services, such as voice with video, will soon become a reality.   Many service applications are being developed to take advantage of the increasing bandwidth.  One such service is Video on Demand.

Video On Demand is a recent 'hype' in the field of multimedia networking. A major challenge in providing VOD in today's Internet is how to transmit real time video streams across a heterogenous best effort network while ensuring an acceptable quality of service. Because the video stream is variable bit rate, the bandwidth requirement is variable. The interarrival time for each frame must lie within a specified delay bound in order for the frame to be useful. Packet losts due to congestion inside the network could also degrade video quality.  However, video is typically transmitted using UDP, which treats each video packet independent of each other, provides no service guarantees and no feedback to the sender.

In order to improve the received video quality, there are two possible approaches. The first one, an end to end approach, is to design and implement network aware VOD servers and clients. The server utilizes feedback information from the client about the network connection and the client's reception to adjust its transmission. There is a question of whether the feedback of previous performance and network conditions will be a sufficient predictor of the future and will be relevant enough to be used by the server.

The second approach is to have intermediate nodes in the network (ie. active routers) which understand the semantics of the VOD application and will assist in providing an acceptable quality of service. For example, using MPEG encoding, upon congestion, the active router will try to avoid dropping I and P frames and will drop only B frames. This capability is not available in today's Internet.

In my project, I will be developing a prototype for the first approach.  A VOD system will be implemented using RTP[2]/UDP as the transmission protocol.  The client will be performing real time decoding of the MPEG stream.  The issues of error resiliency and adapting to packet losses will be investigated on the client side.  Also, for adaptation on the server side, network status feedback from the client will also be used.

Back to the Top

Background

Due to stringent delay constraints, real time multimedia information is transmitted over the network using non-reliable protocols. These network transactions are time sensitive. Minimal transmission delays are tolerable, but long delays could cause jerky, discontinuous motion. This is not perceptually pleasing. Due to the uncertain nature of network load and routes, packets could have delays, or arrive out of order. When the network is congested, packets could even be dropped. Because the unreliable characteristic is inherent to all networks, it is difficult to assure certainty. Current schemes to perform error corrections and retransmissions exist, but they often add on excessive overhead (eg. Forward Error Correction) or more undesirable delays.  Instead of using additional mechanisms to ensure reliable and ordered transmission of video packets, we focus on the end to end adaptation.  The server should respond gracefully to changing network conditions.  The client should also tolerate packet delays and losses.  These two issues will be discussed in the following sections.

The tansport level protocol that will be used for the VOD system is RTP (Real Time Transport Protocol) on top of UDP (User Datagram Protocol).  RTP was chosen because of its apprpriate for carrying real time information.  It also does not provide any guarantees and leaves it up to the application to choose suitable mechanisms.

Network Aware Server Adaptation

To cope with network congestion, it would be useful if the VOD server and client maintain a feedback channel.  The client will periodically send status information back to the server.  This information can include such information as loss rates, delay, delay jitter and perceived video quality.

Error Resilient Client

Assuming that there will always be packet losses and delays, clients need to be as error resilient as possible.  Clients should respond well to packet losses and should have mechanisms to adjust video quality saccordingly. A buffer between the network interface and the mpeg decoder needs to be implemented.  This buffer will act as a rate matcher between the two.

Back to the Top

Implementation

Platform:

Server 

1. A Simple VOD server: The server implemented for the midterm project is a simple server.  There are 2 implementations.  The first one uses TCP/IP as a reliable transmission protocol.  It was used in the demo because the decoder could not handle any packet misordering or losses, yet.  The second implementation uses RTP/UDP/IP, a non reliable transmission protocol.  This will be used when the full decoder modifications have been made.  The server starts up and waits for a client to connect.  Once a client connects, the server packetizes the MPEG stream and transmits it to the client.

2. Usage: send mpeg_filename
 
Client  

1. Choosing MPEG players: The focus of the project is to experiment with end to end characteristics of MPEG video transmission. Thus, the approach was to build a network interface on top of already implemented MPEG decoders.  Various public domain software implementations of MPEG decoders were evaluated.  The minimum requirements are: 

  • MPEG 2 decoder
  • Full X Windows Display Support
  • Piecemeal decoding (the entire bitstream does not need to be examined while decoding) 
  • Basic Network Interface (if possible)
  • Compilable Source Code
However, many problems were encountered. Most public domain implementations do not distribute source code.  Only executables are available.  Some executables also relied on dynamic libraries.  The compiled library path was different from our local machine.  Because source code was needed , our choices were limited.  An MPEG2 decoder with full X windows display capabilities was not found.  Thus, the Berkeley implementation (mpeg_play) of an MPEG1 decoder was chosen.  It was the most stable implementation. 
RED title 
 
 
 
2. Modifications to mpeg_play: mpeg_play, however, only met two of our minimum requirements, full X Windows display support and compilable source code.  The MPEG1 decoder needed to read the whole MPEG stream in (from a file) two times.  In the first pass,  bitstream syntax check and variable initialization were performed.  The second pass was the actual decoding and image displaying.  In order to use mpeg_play in the project, mpeg_play had to be modified.  The modifications are: 
  • Build a network interface
  • Extend the decoder such that it can decode without having to look at the entire bitstream for real time encoding
Two network interfaces were implemented.  One using TCP/IP and the other using RTP/UDP/IP to go along with the server's protocol (mentioned above).  Work on extending the decoder to parse the bitstream picture by picture is currently in progress.  Although it seems trivial, it is more complicated.  There are many issues to deal with, such as there needs to be a level of buffering between the network and the decoder.  The buffering should also reorder packets and cope with loss.
Snapshots of an MPEG 1 video stream used in the project.
 
 3. Usage: mpeg_play [-server server_hostname] [tmp_filename]
This implementation requires that the whole mpeg bitstream be buffered at the client side before decoding. Since mpeg files are large, we cannot store everything in memory. Therefore, parts of the bitstream are written to disk and read back into memory when we do decoding.

Back to the Top

Future Work  (For Final Project)

1. Adaptive Server
The appropriate type of feedback and the frequency of feedback reports will be determined.  There should not be significant overhead in processing the feedback on both client and server sides. In addition, the amount of feedback should scale nicely with increasing number of clients.

2. Error Resilient Client
Initial buffering of the stream (before any decoding) is needed so that delays can be absorbed.  This amount of buffering should be enough so that it can absorb jitters without taking up too much memory resources.  Packets arriving out of order will be ordered at the buffer and, then, passed on to the decoder.  Also, the buffer management scheme should be efficient in that if a packet is loss, subsequent packets that rely on the lost one should not be stored.  For example, if a P frame is lost, newly arriving B frames that rely on that P frame should be dropped.  It is also possible to have the buffer do some form of interpolation for the lost frame for better video quality.  Although the last two features are in conflict with each other, both have positive impact. Finding a balance between the two is important for an error resilient client.

3. Extensions to mpeg_play and server:
To support the above features.
 
Back to the Top

Links and Software Tools

18-899 Class Homepage

Networking

 

MPEG software 

Back to the Top

References

MPEG Standards Committee

MPEG.org

RFCs

[1] D. Hoffman, G. Fernando, V. Goyal, M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", STD 1, RFC 2250, January 1998.

[2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 1, RFC 1889, January 1996.

Internet-Drafts:

 
Back to the Top
 

Kunwadee Sripanidkulchai
Last modified: Wed Mar 11 19:42:44 EST