Video Source Coding & Congestion Control

An Integrated Source Coding and Congestion Control Framework for Video Streaming in

the InternetKang-Won Lee (UIUC), Vaduvur Bhargavan(UIUC), Tae-eun Kim(UIUC), Rohit Puri(UCBERKELEY),

Kannan Ramachandran(UCBERKELEY)

• Features coordinated operation of an application-layer video source coding algo and a transport-layer rate control mechanism

• Transforming a MR(Multi-resolution) bitstream into an MD(Multi Description) packet stream using efficient erasure codes

• TCP friendly rate control algorithm using history

IEEE INFOCOM 2000

Introduction

Current networksSender Probes network for connection capacity. Increases transmission rate until packets are dropped.

Routers drop packets oblivious to the structure and content of the packets.

This network design is unacceptable for video packet, 2 reasons• Video-encoded bitstreams are highly stuctured e.g. characterized by a hierarchy of importance layers. • Most current congestion control algorithms follow the probe-loss-throttle principle and hence cause to

reduce transmission rate even if the loss is not persistent(i.e. due to sudden burst errors).

The above lead to low quality in the delivered video. Hence an efficient transcoding mechanism is required that converts the MR based prioritized bitstream into a non-prioritized packet stream while ensuring graceful quality degradation when there is a packet loss.

Proposal• Transcoding mechanism based on MD robust source coding principles, anchored on FEC channel

codes.• LIMD/h – Implementing LIMD with history to ensure graceful handling of loss of packets.

Block Diagram of System

• FEC Based MD Coding• A. Transcoding Mechanism• B. Optimal Allocation algorithm• Congestion Control• A. Framework for Congestion Control• Coordination of Transcoder and Congestion Control

FEC based MD coding• Conversion of the prioritized MR bitstream into unprioritized MD stream using efficient erasure

channel codes.

Terminology • Quality profile : The quality experienced at the receiver as a function of number of packet losses

of the generated stream. This has the property of graceful degradation with respect to packet losses.

• Rate Budget : The maximum number (N) of packets of Length L that can be injected into the network

• Transmission profile : The probability of successfully delivering i packets out of N, for every i.

• Transcoding Mechanism (Fig 2 & Fig 3)• A progressive bitstream from the source coder is partitioned into m layers.

• The ith quality layer is futher divided into N – m + i equal parts and apply the (N, k, N – k + 1) Reed-Solomon code to get the contribution from the ith layer to each of the N descriptions. See figure 2 and 3

Transcoding Mechanism

Optimal Allocation Algorithm

• Algorithm to choosing the optimal division of the progressive bitstream i.e. value of m in Fig 1.

Where E is the distortion encountered when the source is represented by 0 bits. Since quality is a 1-1 function(D(r)) of the rate r, ascertaining the quality profile d(k) of order N corresponds to finding the rate partition

The total Rate equals, i.e. if m = N, then the total Rate becomes

Problem StatementGiven the number of packets N, each packet of size L(i.e. total rate budget R* = N * L), a bistream withrate-distortion D(r), and the transmission profile Find R that minimizes ED subject to (resource constraint) and

Lagrange Multipliers is used to obtain the optimal solution.

Algo(Contd)

Since is a constant at optimality, for monotonically decreasing values of the absolute

value of has to be a monotonically decreasing sequence in i. Hence

2 observations are made

If the optimal solution to the original problem is the same as that to a reduced

Problem where is replaced by so that

Also

Meaning : The above observation can be successively applied to a monotonically increasing

or flat section in the profile, and all the corresponding rate variables are equal in the

optimal solution thus reducing the dimensionality of the problem.

Algo(Contd)

Algo(Contd)

Congestion Control

• Current congestion control algorithms use the LIMD(Linear Increase Multiplicative Decrease) for both window-based and rate-based congestion control. We are interested in rate-based congestion control because its more suited to multimedia applications.

• Review of LIMD : Increases rate by an additive constant upon observing no packet losses and aggressively decreasing the sending rate by a multiplicative constant upon observing packet losses(in order to alleviate congestion).

• Persistent Congestion : A congestion caused by reduction in the “fair share” of the network bandwidth for the connection

• Non-persistent congestion : Losses induced by the sender probing for additional bandwidth or random channel loss in wireless networks.

• Propose an algorithm called LIMD/H(LIMD with history) that augments LIMD with an additional mechanism to differentiate the cause of packet losses and take adaptive action accordingly. Features of LIMD/H are

• A. Uses the history of packet losses in order to distinguish between persistent congestion and non-persistent congestion

• B. Reacts gently to non-persistent congestion, but reacts aggressively to the onset of persistent congestion.

Congestion control framework and algorithm

• A. Framework

• Discrete time periods called epochs are used.

• A monotonically increasing sequence number is assigned to each packet by the sender.

• At the end of each epoch, the receiver computes the fraction of received packets over the range of packet sequence number during the epoch. Receiver then sends a congestion feedback to the sender containing the loss fraction

• On receiving the loss feedback, the sender executes the LIMD/H algorithm to adjust its sending rate.

• B. LIMD/H Algorithm

• The vanilla LIMD. Let denote the sending rate, denote the loss fraction, denote the linear increase constant, and denote the multiplicative decrease constant. Using LIMD

• The fundamental problem is to relate the rate throttling factor to the cause of packet loss.

Congestion control(contd)

• An intuitive and simplistic heuristic to predict persistent congestion is : if the packet losses observed during an epoch are caused by persistent congestion, but the sender does not throttle aggressively enough, then the loss will continue;

• if the packet loss is a probe loss, then so long as the sender throttles enough to account for the loss, there will be no loss in the next epoch.

• LIMD/H : The h variable reflects the history and is initialized to 1, is doubled if there is a packet loss in an epoch, and reset to 1 if there is not. h variable effectively captures the history of packet loss in previous epochs.

• is typically set to a small value (between 0.1 & 0.2) in order to achieve gentle throttling when there was no packet loss in the previous epoch, and progressively more aggressively when previous epochs have experienced packet loss. See Fig 6 in next page.

• If is maintained at the same value as in LIMD, then the channel probe is aggressive as before but rate throttling is less aggressive thereby inducing more packet drops. Hence, we need to adjust as shown below.

LIMD/H graph

Congestion control algo

• Approach is to trade-off the aggressiveness in the increase phase for gentle throttling in the decrease phase, while still allowing for an exponential increase in the throttling factor in order to account for sudden congestion and to prevent congestion collapse.

• Throttle gently upon initially observing loss, and then throttling the rate more aggressively by exponentially increasing the throttling factor when we predict persistent congestion.

• Properties of LIMD/H

Coordination of Transcoder and Congestion control

• LIMD/H is able to provide a fairly accurate estimate of the connection capacity, and an aggregation of the transmission rate samples from the LIMD/H algorithms can be used to generate an accurate transmission profile.

• Figure shows the interaction between the source transcoder, LIMD/H congestion control algo and the interaction layer between the two

Coordination of transcoder and congestion control

• How are the transmission profile and the rate Budget computed?

• How should the interaction between the transcoder and the transport be achieved?

• A set of pairs based on the transmission rate history is calculated. The is the probability of achieving an effective transmission rate of Given this profile and a maximum allowable rate budget we can generate exactly how many packets can be transmitted in an epoch, and convert rate-based probabilities to packet based probabilities required by the transcoder.

• The transport layer and the source coder interact as below

• A. Congestion control module in the kernel queues the effective transmission rate into the kerneldq message queue. This message queue is a special queue that is accessible to both the kernel and the kerneld daemon

• B. When the kerneld gets scheduled periodically, it dequeues the messages from the kerneldq message queue, and signals the appropriate process.

• C. The runtime library then uses the effective transmission rate samples in order to update its transmission profile

Calculation of Transmission profile and rate budget.

• To calculate transmission profile

• Maintain a weighted running average of the frequency of occurrence of each rate sample

and generate the transmission profile by normalizing the frequencies.

where in order to maintain the long history, and is the number of instances of

in the kerneldq during the invocation of the transmission profile generator.

• Estimate the rate budget

• Choose to be the smallest value at which the aggregate probability of exceeding the rate is under 5% i.e.

• Reduce by an amount that is proportional to the usual rate decrease in a steady state i.e.

where is a tunable constant, is the decrease factor, and is the graded decrease factor in LIMD/H.

• The updated transmission profile and rate budget are passed onto the transcoder periodically

Simulation Results

• The ns-2 network simulator was used to implement the congestion control algorithms as a part of the transport layer protocol.

• Used a parameterized version of the “Football” video sequence as encoded by the start-of-the-art embedded video encoder, namely the 3-D SPIHT encoder

• The frame size is 352 x 240 pixels and each GOP comprises of 16 frames.

• The transmission speed chosen was 1 GOP per epoch, where each epoch has a duration equal to 650 msec, which corresponds to approximately 26.7 frames per second.

• The reference scheme for the congestion control mechanism is LIMD.

• The reference systems for robust video encoding are :

• A. Multi resolution (MR) Source encoder (no robustness against packet loss)

• B. Constant FEC or Equal Error Protection(EEP) (different layers of the prioritized bit stream are assigned with the same level of error protection i.e. source unaware channel encoding since layers of different importance are encoded by identical protection)

• C. Fixed Unequal Error Protection (FUEP) (different layers of the prioritized bit stream are assigned with unequal error protection that is fixed)

• The next table(Table I) shows the performance and characteristics of the reference systems

Simulation Results(Contd.)

Simulation Results(Contd.)

• The performance of the video transmission was compared in terms of the measured delivered quality at the receiver(or peak signal-to-nose ratio (PSNR) in dB) and the smoothness of the quality variation over time perceived by the user.

• A. Compare the effect of candidate congestion control algorithms

• B. Compare the robust mechanisms

• C. Performance in a large network.

• All results are presented with PSNR (dB) on y-axis and time(second) on x-axis.

Comparison of congestion control schemes

• Ideal network support for transmission of prioritized source consists of smart priority dropping switches in face of congestion.

• Network topology is shown in Fig 9. LIMD delivers a widely varying quality while LIMD/H delivers a near constant quality (Fig 8).

Simulation Results(Contd.)

Simulation Results(Contd.)

Comparison of source robustness mechanisms

See Fig 10 and Fig 11(next page)

Simulation Results(Contd.)

Simulation Results(Contd.)

Simulation Results(Contd.)

Simulation Results(Contd.)

Performance in a Large network

• There are 2 video streams and 10 TCP connections

• The link capacity and the one-way delay is annotated on the graph. All links without annotation were set to 40 Mbps and 20 msec.

Simulation Results(Contd.)

FutureWork

• Estimation of the transmission profile. Exploring more sophisticated traffic models to estimate this profile.