Empirical evaluation of the congestion responsiveness of RealPlayer video streams

Abstract

Abstract-Increasingly popular commercial streaming media applications over the Internet often use UDP as the underlying transmission protocol for performance reasons. Hand-in-hand with the increase in streaming media comes the impending threat of unresponsive UDP traffic, often cited as the major threat to the stability of the Internet. Unfortunately, there are few empirical studies that analyze the responsiveness, or lack of it, of commercial streaming media applications. In this work, we evaluate the responsiveness of RealNetworks' RealVideo over UDP by measuring the performance of numerous streaming video clips selected from a variety of RealServers on the Internet, analyze the TCPFriendliness of the UDP streams and correlate the results with network and application layer statistics. We find that most RealVideo UDP streams respond to Internet congestion by reducing the application layer encoding rate, and streams with a minimum encoding rate less than the fair share of the capacity often achieve a TCP-Friendly rate. In addition, our results suggest that a reason streaming applications choose not to use TCP is that the TCP API hides network information, such as loss rate and round-trip time, making it difficult to estimate the available capacity for effective media scaling.

ARMOR – A system for adjusting repair and media scaling for video streaming

“…3 The first video pair was a training exercise designed to provide the user with an understanding of the evaluation system and to serve as a baseline for the ''worst" quality video presented. For training, the original clip was played followed by a severely degraded version with only the ''much worse" option available for selection.…”

Adjusting forward error correction with temporal scaling for TCP-friendly streaming MPEG

“…These settings yield a packet rate of 146 packets per second and a data rate of 1.168 Mbps for the MPEG video. The packet size s, roundtrip time t RT T and packet loss probability p were chosen based on the characteristics of many network connections [Paxson 1999;Chung et al 2003;Jaiswal et al 2004]. For all experiments, the parameters are fixed, except for the packet loss probability p, which ranges from 0.01 to 0.04 in steps of 0.001.…”

“…We used a series of traces from an Internet measurement study [Chung et al 2003] to simulate the effects of bursty loss over a range of loss conditions. For each loss event, we used the probability distribution obtained from Internet streaming traces in [Loguinov and Radha 2001] and depicted in Figure 5a, to provide bursty loss events.…”

“…The possible impact of variable RTTs is that the bandwidth estimate using a fixed average RTT is inaccurate, and therefore this causes the choices for temporal scaling and FEC to be less effective. To study the effects of variable RTTs, we selected a trace from [Chung et al 2003], depicted in Figure 6a, that had an average RTT of about 45 milliseconds.. We used our model to determine the adjusted FEC and temporal scaling patterns assuming a fixed RTT of 50 milliseconds. Then, we simulated streaming the MPEG video using the RTT trace and measured the actual frame playout rate at the receiver.…”

Adjusting forward error correction with quality scaling for streaming MPEG

“…A commonly-used MPEG GOP pattern, 'IBBPBBPBBPBBPBB', and a typical full motion frame rate RF of 30 frames per second (fps) are used. The packet size s, round-trip time tRT T and packet loss probability p are chosen based on the characteristics of many network connections [1,5]. For all experiments, the parameters are fixed, except for packet loss probability p, which was varied from 0.01 to 0.04 in steps of 0.002.…”