To implement Video streaming over TFRC -Manigandan Natarajan -Manigandan Natarajan

Project goals (for this semester) Study in detail how Video streaming can be done over TFRC To study about various Streaming transport protocols - RTP (Real Time Protocol) to be more specific and how they work with TFRC. To study about other congestion control protocol like DCCP (Datagram congestion control protocol) How the different types of streaming might handle feedback (via tfrc transport) (This is a big question … how can streaming work with tfrc)

Project Goals (contd…) Add videoconferencing and streaming capabilities in to our lab. Figure out how to run them over tfrc. Once we do this, we can do a performance assessment. Take a look at developing a way to monitor the QoE (Quality of Experience) associated with streaming audio/video. Figure out a way to add the streaming performance assessment to Dr.Martin’s performance tool.

Project Topic The evaluation of TFRC when transporting streaming (audio or video) data The development and design of a tool that monitors the ability of a network to transport streaming data.

Why not UDP or TCP? TCP can introduce arbitrary delay because of its reliability and in- order delivery requirements Even today most of the real time applications use UDP as a transport protocol. But UDP is considered selfish and ill behaving because TCP throttles its transmission rate against network congestion where as UDP does not have any congestion control mechanism. As a result a considerable amount of greedy UDP traffic would dominate the network bandwidth. As of now the congestion control is implemented in the individual applications on a case-by-case basis.

Why TFRC or DCCP(CCID 3) for Video TFRC is a rate-based end to end congestion control protocol instead of window based. Instead of reacting to single congestion events like TCP, the TFRC protocol changes its sending rate in response to loss rate, sampled over a period of time. Its short term sending rate is more stable as compared to TCP This make s the protocol suitable for traffic where sudden rate changes are undesirable( for e.g. video)

What is TCP- Friendly? TCP-friendly is defined as ”a non-TCP connection should receive the same share of bandwidth as a TCP connection if they traverse the same path. A TCP-friendly system regulates its data sending rate according to the network condition, typically expressed in terms of the round-trip- time (RTT) and the packet loss probability, to achieve the same throughput that a TCP connection would acquire on the same path.

Basic TFRC protocol The sender sends a stream of data packets to the receiver at some rate. The receiver sends a feedback packet to the sender at least once every round-trip time. Based on the information contained in the feedback packets, the sender adjusts its sending rate in accordance with the TCP throughput equation, to maintain TCP-friendliness. If no feedback is received from the receiver in several round-trip times, the sender halves its sending rate. The values of the round-trip time RTT, the loss event rate p and the base timeout value TO are needed by the sender to calculate the send rate using the TCP throughput equation. The sender calculates the values of RTT and TO, while the receiver calculates the value of p.

Things to be done (contd…) The big question in our project is whether to focus on Live Internet streaming ( for e.g. Live games, live interviews, live movies) Or To focus on video transfer from a high bandwidth to low bandwidth with a bottle neck in between. - As of now we have decided to have both the options open and work on other aspects of the project.

Directions to our project The initial thrust will be on live streaming. In our lab, we will setup a live streaming server using the encoder/RTP/tfrc system. We want to assess the quality of the video as perceived by the end user. Then we want to evaluate this system, focusing on the trfc protocol. Of particular interest are any tfrc changes, tweaks, configuration items that one might change and their impact on the perceived quality. we will use the tfrc library for this work. we will also develop a similar streaming system that uses an unresponsive UDP protocol. This will give us something to compare with.

Directions (Next big Leap) A follow on will be to add pieces of our work in to Dr.Martin network management tool. The tool should be able to assess if a certain network (i.e., a large corporate network or a particular WAN service) can transport video data. One approach is to have the tool periodically probe the network with artificial video/audio streams (perhaps one flavor that uses traditional UDP streaming transport and another that uses tfrc transport) and based on our QoE algorithm makes an assessment decision.

Direction (Final Leap) A further follow on will be to will be to consider tfrc in an ISP environment where a web 'portal' provides streaming video/audio content to attract people to its web site. The concern is if too many people start viewing the streamed content, network performance within the ISP occurs. Our possible solution is to build a tfrc streaming delivery system that takes pre-encoded content but streams it out using an adaptive tfrc. We would need to build both the server and the client side of this system.

Things to be done at present…. We need to choose a encoder for our MPEG video stream. - Choice of the encoder is crucial because it directly affects the video quality. -The interaction between TFRC and encoder will prove critical in live video streaming (if we choose to implement it) -As of now we have narrowed down to FGS (Fine Granularity Scalability ) encoder -We will see a brief introduction to its working in coming slides… -We should learn how to control the encoding process with the TFRC congestion control parameters.

Things to be done (contd….) To find a effective evaluation mechanism for performance assessment and to compare it with a UDP flow. End user based evaluation, where the end user will do a evaluation on the quality of the video. Statistical evaluation based on the average bandwidth consumed and the bandwidth consumed by other TCP and non TCP flows.

Things I need to learn… Learn how to interface between the video encoder and TFRC protocol? - How to correspond the TFRC statistics to the encoder so as to reduce or increase the video rate. -This involves studying in detail about the encoding process so as to determine which parameters affect the video rate of the stream. This project will concentrate on Live video. Learn how to run RTP over TFRC…. –There are some of complication in doing this…. Redundant use of data in two protocol layers Both place a Seq. Number, timestamp in the packet Both employ receiver report mechanism And lot more……..

DCCP A protocol that combines unreliable delivery mechanism with built-in congestion control. DCCP lets applications choose between several forms of congestion control. One choice, TCP-like congestion control, halves the congestion window in response to a packet drop or mark, as in TCP. A second alternative, TFRC (TCP- Friendly Rate Control, a form of equation-based congestion control), minimizes abrupt changes in the sending rate while maintaining longer-term fairness with TCP.

RTP RTP provides end-to-end network transport functions suitable for applications transmitting real-time data such as audio or video and is designed to be independent of the underlying transport and network layers. Real-time application usually use the underlying transport layer as UDP. That delivery protocol doesn’t care about the network state of traffic congestion just to get available bandwidth as much as possible.

A brief intro to MPEG-4 coding scheme An MPEG-4 video stream consists of three types of VOPs. VOP is the basic unit of image data and is equivalent to the frame or picture.

3 types of frame in MPEG-4 I-VOP is a self-contained intra-coded picture and coded using information only from itself. P-VOP is predictively coded using motion compensation algorithm referring to the previously coded VOP. B-VOP is a bi-directionally predictive-coded VOP using the differences between both the previous and next VOPs. An I-VOP is directly and indirectly referred to by all following P and B-VOPs until another frame is coded as an I-VOP. Since an entire frame can be completely reconstructed from an successfully received I-VOP, error propagation can be interrupted when video quality is degraded in the preceding VOPs due to accidental packet losses.

Overall coding structure of FGS The basic idea is to code a video sequence in to a base layer and enhancement layer. The base layer is generated using motion compensation and DCT and provides minimum video quality. The enhancement layer is to code the difference between the original picture and the reconstructed picture using embedded DCT method. The bit stream of FGS enhancement layer may be truncated into any number of bits per picture after encoding is completed. The decoder will reconstruct an enhanced video from the base layer and the truncated enhancement layer bit streams.

Architecture of FGS layers The below figure shows how the enhancement layer can be truncated according to the network conditions without drastically affecting the picture quality.

Advantages of FGS encoding It is very simple to implement it both in coder and decoder side. FGS-EL can be truncated anywhere. –This property allows the EL bit stream to be cut and packetized during transmission according to the available bandwidth of the connection.

Big Question? Are we going to build the FGS encoder? - NO. We should borrow the source code. We are going to make changes to the FGS encoder so that it changes its rate according to the TFRC parameters. Again I don’t have a clue as how to implement this. I am in touch with a Ph.D guy in Georgia Tech. He is also working on Video streaming. He has already acquired source code from Philips Lab (copyright owner of FGS code).

Current status of TFRC in video streaming When I contacted a top researcher in TFRC-Video this is what he said “As far as I know, there's nobody having developed any commercial/non-commercial application over TFRC. Actually, if you make some experiments, you can find that streaming without any congestion/flow control achieves the best result although it is not desirable. So most applications does not employ any flow/congestion control. Instead, they simply transmit at the data rate at which a video was encoded.” But he also added that in coming years TFRC will play a major role in video streaming as modifications are made to it.