streaming over TFRC

rawsulkyInternet and Web Development

Dec 11, 2013 (3 years and 6 months ago)


To implement Video
streaming over TFRC

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

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

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
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 is defined as ”a non
TCP connection should receive
the same share of bandwidth as a TCP connection if they traverse
the same path.

friendly system regulates its data sending rate according to
the network condition, typically expressed in terms of the round
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

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

If no feedback is received from the receiver in several round
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)


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

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


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


A protocol that combines unreliable delivery mechanism with built
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
based congestion control), minimizes abrupt changes in
the sending rate while maintaining longer
term fairness with TCP.


RTP provides end
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

A brief intro to MPEG
4 coding scheme

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

VOP is a self
contained intra
coded picture and coded using
information only from itself.

VOP is predictively coded using motion compensation algorithm
referring to the previously coded VOP.

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
VOPs until another frame is coded as an I

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.

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

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

When I contacted a top researcher in TFRC
Video this is what he

“As far as I know, there's nobody having developed any
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.