streaming over TFRC

rawsulkyInternet and Web Development

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

70 views

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