WPI-CS-TR-02-17May2002 FairPlayer or FoulPlayer?-Head to Head Performance of RealPlayer Streaming Video Over UDP versus TCP
by
Jae Chung
Yali Zhu and Mark Claypool
Computer Science Technical Report Series
Computer Science Department
100Institute Road,Worcester,Massachusetts01609-2280
1 FairPlayer or FoulPlayer?-Head to Head Performance of RealPlayer Streaming Video Over
UDP versus TCP
Jae Chung,Yali Zhu and Mark Claypool
Computer Science Department
Worcester Polytechnic Institute
100Institute Road
Worcester,MA01609
goos|yaliz|claypool@https://www.doczj.com/doc/8b11459329.html,
Abstract—The growth in power and connectivity of to-day’s PCs promises a continued increase in streaming me-dia over the Internet.Hand-in-hand with the increase in streaming media comes the impending threat of unrespon-sive traf?c,often cited as the major threat to the stability of the Internet.The responsiveness of commercial stream-ing media applications will play an important role in the network impact of streaming media.Unfortunately,there are few empirical studies that analyze the responsiveness,or lack of it,of current streaming media products.In this work, we measure the responsiveness of RealVideo over UDP com-pared with RealVideo over TCP by simultaneously playing video clips selected from numerous RealServers on the In-ternet to two distinct video clients along the same network path.By varying the bottleneck bandwidth to the clients, we are able to analyze the“head-to-head”performance of RealVideo over UDP as compared to RealVideo over TCP, and correlate the results with network and application layer statistics.We?nd that most streaming RealVideo clips are not bandwidth constrained for typical broadband connec-tions,resulting in a fair share of link bandwidth used by both RealVideo over TCP and RealVideo over UDP.In times of congestion,most RealVideo over UDP does respond to In-ternet congestion by reducing the application layer encod-ing rate,often achieving a TCP-Friendly rate.In times of severe congestion,RealVideo over UDP gets a proportion-ately larger share of available bandwidth than does the same video over TCP.
Keywords—RealPlayer,Video Streaming,TCP,UDP, Fairness
I.I NTRODUCTION
The growth in power and connectivity of today’s com-puters has enabled streaming video across the Internet to the desktop.Increasingly,users can access online video clips through a Web browser by simply clicking on a link and having the Web browser start up an associated video player.Web sites today offer streaming videos of news broadcasts,music television,live sporting events and more.For example,in2001an estimated of350,000hours of online entertainment was broadcast each week over the Internet[1],with countless more hours downloaded on-demand.
While voice quality audio typically operates over a nar-row range of bandwidth(32-64Kbps),video operates over a much wider range of bandwidths.Video conferences and Internet videos stream at about0.1Mbps1,VCR qual-ity video at about1.2Mbps2,broadcast quality video at about2-4Mbps3,studio quality video at about3-6Mbps3, and HDTV at about25-34Mbps3.Uncompressed video can require hundreds and even thousands of Mbps.Thus, video applications have the potential to reduce their data rates when bandwidth is constrained but also have a po-tential to demand enormous amounts of bandwidths,often greater than the available network capacity.
While TCP is the de facto standard transport protocol for typical Internet applications,there are as of yet no widely accepted rate-based transport protocols for multi-media.Unlike typical Internet traf?c,streaming video is sensitive to delay and jitter,but can tolerate some data loss. In addition,streaming video typically prefers a steady data rate rather than the bursty data rate often associated with window-based network protocols.Recent research has proposed rate-based TCP-Friendly protocols in the hope that streaming media applications will use them[2],[3], [4],but such protocols are not yet widely part of any op-erating system distribution.For these reasons,stream-ing video applications often use UDP as a transport pro-tocol rather than TCP.Moreover,with the use of repair
H.261and MPEG-4
MPEG-1
MPEG-2
2
techniques[5],[6],[7],[8],packet losses can be par-tially or fully concealed,enabling streaming video to op-erate over a wide range of packet loss rates.Repair tech-niques can reduce the impact of loss on the quality of the video by the user,thus reducing the incentive for multi-media applications to reduce their bandwidth in the pres-ence of packet loss during congestion.Potentially high-bandwidth video over UDP using repair techniques sug-gests that video?ows may not be TCP-friendly or,even worse,that video?ows may be unresponsive to network congestion.
In the absence of end-to-end congestion control,TCP ?ows competing with UDP?ows reduce their sending rates in response to congestion,leaving the unresponsive UDP?ows to expand to use the vacant bandwidth,or, worse,contribute to congestion collapse of the Internet[9]. In light of this,recent research has explored router queue management approaches to identify and police unrespon-sive?ows[10],[11],[12],[13],[14],[15],[16].Such research often models unresponsive?ows as transmitting data at a constant packet size and constant packet rate (CBR)or,as”?rehose”applications,transmitting at an unyielding,maximum rate.However,commercial media products have been shown to not be strictly CBR[17], and,although using UDP,may respond to congestion at the application layer.A better understanding of the traf?c rates and responsiveness of current streaming media appli-cations may help create more effective network techniques to handle unresponsive traf?c.
The responsiveness of commercial streaming media products will play an important role in the impact of streaming media on the Internet.The use of commercial streaming products,such as the Microsoft Windows Me-dia Player and RealNetworks’RealPlayer,has increased dramatically[18].Unfortunately,there are few empirical studies that analyze the responsiveness,or lack of it,of current streaming media products.
This study measures the responsiveness of RealVideo over UDP compared with RealVideo over TCP by simul-taneous playing video clips selected from numerous dis-tributed Web servers to two clients along the same net-work path.We set up a network testbed where two clients streamed video through a network router we control,con-nected to the Internet via a broadband connection.We var-ied the bottleneck bandwidth to the clients by limiting the bandwidth of the router’s outgoing connection,allowing us to explore a range of congestion situations.The two clients then simultaneously streamed hundreds of selected videos with a variety of content and encoding formats from a diverse set of servers,while measuring packet loss rates and round-trip times of the connections as well as applica-tion level statistics such as encoding bandwidth and frame rate.By analyzing the“head-to-head”performance of the two video streams,we are able to assess the responsiveness of the video stream over UDP as compared to the video stream over TCP,and correlate the results with network and application statistics.
In analyzing our data,we make several contributions to better understanding the characteristics of potentially unresponsive streaming video on the Internet.We?nd that overall,most streaming RealVideo clips are not con-strained under bandwidth from a typical broadband con-nection,resulting in a fair share of link bandwidth for both RealVideo over TCP and RealVideo over UDP.In times of congestion,most streaming RealVideo does respond to Internet congestion by reducing the application layer en-coding rate.In times of severe congestion accompanied by high loss rates and/or high round-trip times,RealVideo over UDP gets a proportionately larger share of available bandwidth than does the same video over TCP.We also ?nd numerous incentives for video streams to use UDP rather than TCP,which suggests that potentially unrespon-sive streaming media over UDP will likely persist for some time.
The rest of this paper is organized as follows:Section II presents background on RealPlayer needed to understand-ing our results;Section III describes our approach to ob-tain a wide-range of Internet measurements;Section IV and V present and analyze the measurement data obtained; Section VI discusses our?ndings;Section VII summarizes our conclusions and Section VIII presents possible future work.
II.R EAL V IDEO B ACKGROUND RealPlayer,provided by RealNetworks4,is the most popular streaming media player on the US Internet,with over47%of the commercial market share[18].RealVideo content providers create streaming videos using a number of possible video codecs,convert it to RealNetworks’pro-prietary format and place it on an Internet host running RealServer.During creation,content providers select tar-get bandwidths appropriate for their target audience and specify other encoding parameters,such as frame size and frame rate,appropriate for their content.A RealServer then streams the video to a user’s RealPlayer client upon connecting.
RealServer and players primarily use Real Time Stream-ing Protocol5(RTSP)for the session layer protocol.Occa-sionally,RealServer will use HTTP for meta?les or HTML https://www.doczj.com/doc/8b11459329.html,
https://www.doczj.com/doc/8b11459329.html,/
3
pages,and it may also be used to deliver clips to Re-alPlayer clients that are located behind?rewalls.For this measurement study,all the video clips selected used RTSP, as described in Section III-A.
At the transport layer,RealServer uses both TCP and UDP for sending data.The initial connection is often in UDP,with control information then being sent along a two-way TCP connection.The video data itself is sent using either TCP or UDP.By default,the actual choice of trans-port protocol used is determined automatically by the Re-alPlayer and RealServer,resulting in UDP about1/2the time and TCP the other half[19].The choice of UDP or TCP can also be speci?ed by the user[20].For our study, we speci?cally set RealPlayer to use UDP in some cases and TCP in others,as described in Section III-B. RealSystem supports an application level media scaling technology called SureStream in which a RealVideo clip is encoded for multiple bandwidths[21].When stream-ing a SureStream RealVideo clip,RealServer determines which encoded stream to use based on feedback from Re-alPlayer regarding the current network conditions.The ac-tual video stream served can be varied in mid-playout,with the server switching to a lower bandwidth stream during network congestion and then back to a higher bandwidth stream when congestion clears.We study the?exibility of SureStream scaling in Section V-F.
For each video clip,RealPlayer keeps a buffer to smooth out the video stream because of changes in bandwidth,lost packets or jitter.Data enters the buffer as it streams to RealPlayer,and leaves the buffer as RealPlayer plays the video clip.If network congestion reduces bandwidth for a few seconds,for example,RealPlayer can keep the clip playing with the buffered data.If the buffer empties com-pletely,RealPlayer halts the clip playback for up to20sec-onds while the buffer is?lled again.We measure the rate at which RealPlayer?lls the buffer in Section V-D.
III.A PPROACH
In order to empirically compare and contrast the perfor-mance of RealVideo over UDP with RealVideo over TCP, we employed the following methodology:
Select RealVideo URLs that use the Real Time Stream-ing Protocol(RTSP)using well known Web search engines (see Section III-A).
Construct a“head-to-head”environment for comparing network layer performance of two competing RealVideo streams,UDP and TCP,that simultaneously playout a Re-alVideo clip(see Section III-B).
Construct a“media scaling”environment for comparing the application layer behavior of non-competing UDP or TCP RealVideo streams(see Section III-C).
en-
the A.
search engines,such as Yahoo and Google,and randomly selected100RTSP RealVideo URLs from the search re-sults.Of the selected URLs,76are from the United States,9from Canada,8from the UK,6from Italy,and 1from Germany.While our selection method of using US/English based commercial search engines likely in?u-enced the predominance of North American URLs,our RealPlayer clients ran from North America and it is likely that there is typically strong locality of access for most streaming players.Other statistics on the selected Re-alVideo URLs(or clips)are available in Section IV and Section V-F.
B.Head-to-Head Comparison Environment
To compare the network layer performance of Re-alVideo over UDP and RealVideo over TCP,we had two RealPlayers,one using UDP and the other using TCP,si-multaneously stream video from the same URL,along the same network path,while we captured network statistics. As depicted in Figure1the two RealPlayers ran on sepa-rate PCs,attached to the same10Mbps hub.Each PC was equipped with Pentium III700MHz processor,128MB RAM and a UDMA-6615GB hard disk,and was running Linux kernel version2.4.Both PCs ran RealPlayer version 8.0.3,with one RealPlayer con?gured to use UDP and the other RealPlayer con?gured to use TCP.
While the testbed network setup did not guarantee that two streams with same source and destination address al-ways traveled the same network path,the relatively per-sistent characteristics of Internet routing[22]suggest they shared the same route in most cases.Also,any routing changes made during streaming applied to both TCP and UDP streams.
4
The hub facilitated capturing network layer perfor-mance since packets destined to either PC were broad-casted to both PCs.We ran tcpdump6,a well-known net-work packet sniffer,on one PC to?lter and log the video stream packets.During pilot studies,we veri?ed that the packet?ltering and logging did not induce much CPU nor disk load and did not interfere with the video playout.At the end of each RealVideo stream,information such as the IP packet size and arrival time were extracted from the tcp-trace log using ethereal7and processed to obtain net-work layer statistics,such as throughput.
We wrote an expect script to automate the process of starting RealPlayer on each client and measuring net-work layer performance.For each RealVideo URL in our playlist(from Section III-A),the script contacted the Re-alServer to see if it was alive.If so,the script then started a tcpdump and a ping(at1second intervals)ping)to the server to obtain samples of the round-trip time and packet loss rate.Next,the script ran one RealPlayer on each of two client PCs simultaneously,one player using TCP to play the clip and the other player using UDP to play the clip.If more than a minute passed without tcpdump re-ceiving a packet,the script stopped the players and the log-ging,and produced the desired network layer performance statistics.
Initially,our testbed network was connected to our cam-pus LAN which is connected to the Internet via a15Mbps link8,and10“head-to-head”sets of experiments were car-ried out,but that setup showed few signs of network con-tention,making it dif?cult to measure the responsiveness of RealVideos.The UDP and TCP video streams shared bandwidth fairly as bandwidth was not constrained,a re-sult supported by an earlier study[23].In order to reduce the bottleneck bandwidth,the testbed was connected to a commercial DSL network that offers a maximum band-width of700Kbps,as shown in Figure1(without the token bucket?lter),and10“head-to-head”sets of experiments were carried out.Unfortunately,700Kbps was still not constrained enough to create a bottleneck for two typical RealVideo streams.
In order to more effectively control the incoming band-width,we set up a private router connected to the DSL con-?guration to enable us to created constrained bandwidth situations.We attached a software implementation of a Token Bucket Filter(TBF)9to the Ethernet card at the in-ternal network of the router,a Linux PC.The TBF queue https://www.doczj.com/doc/8b11459329.html,/
https://www.doczj.com/doc/8b11459329.html,/
https://www.doczj.com/doc/8b11459329.html,/Admin/Netops/MRTG/
https://www.doczj.com/doc/8b11459329.html,/archive/howto/Adv-Routing-HOWTO-7.html#ss7.3size was set to10Kbytes and the burst allowed(the max-imum number of tokens available during idle times)was set to1600Bytes,slightly larger than a typical1500Byte MTU.The token rate(available bandwidth)was set to600 Kbps,300Kbps,150Kbps and75Kbps.Note,since we have two streaming?ows,one TCP and one UDP,com-peting,their fair share is approximately half of each bot-tleneck bandwidth.With a?xed TBF queue size,the max-imum queuing delay increased as the available bandwidth decreased,as is typical of relatively narrow-band network connections.The DSL-TBF-075con?guration moded a typical narrow-band modem connection with a moderate queue that often results in a high queuing delay.Thus,we had DSL-TBF con?gurations as follows:
DSL-TBF-600:BW=600Kbps,MAX DELAY=133ms DSL-TBF-300:BW=300Kbps,MAX DELAY=267ms DSL-TBF-150:BW=150Kbps,MAX DELAY=533ms DSL-TBF-075:BW=75Kbps,MAX DELAY=1067ms For each DSL-TBF con?guration,we carried out two sets of“head-to-head”measurements,where each set played all video clips in the playlist.For consistency,this paper primarily analyzes the results from the DSL-TBF ex-periments(except for some LAN results in Section V-D), but the LAN and the original DSL measurement results were very similar to that of DSL-TBF-600.
C.Media Scaling Measurement Environment Streaming video can adjust to the available bandwidth during congestion by media scaling[24]where video en-coding is switched to a lower rate.As mentioned in Sec-tion II,RealSystem uses a media scaling technology called SureStream in which a RealVideo clip is encoded for mul-tiple bandwidths[21].The actual video stream served can be varied in mid-playout,with the server switching to a lower bandwidth stream during network congestion and then back to a higher bandwidth stream when congestion clears.
We sought to assess the ability of the RealPlayer appli-cation layer to respond to different levels of congestion.To do this,we needed to measure the number of scale levels typically used in RealVideos and the actual encoded band-width associated with each scale level.The metrics for application level responsiveness,then,are the number of media scales changes seen in a playout and the time taken for the application layer encoded data rate to drop to the available bandwidth during times of congestion.
To study media scaling in RealPlayer we used Real-Tracer,a tool developed for a previous study[19],which plays RealVideo streams and records application level statistics,including encoding rate.Unfortunately,Real-
5
0.10.20.30.40.50.60.70.80.910200400600
800100012001400160018002000C u m u l a t i v e D e n s i t y
Clip Playout Lengths (in Seconds)
Fig.2.CDF of Video Clip Playout Lengths (All Runs)Tracer only runs on Microsoft Windows operating sys-tems,so we were not able to capture application layer per-formance statistics when measuring “head-to-head”net-work layer performance.
Instead,we set up an alternate environment in which one of the client machines in the DSL-TBF environment was booted with Microsoft Windows ME and equipped with RealPlayer 8Basic version 6.0.9and RealTracer version 1.0.We then ran a non-competing,single UDP or TCP stream for each URL in the playlist,while limiting the TBF incoming bandwidth to 35Kbps 10.We tried other TBF rates such as 25Kbps,150Kbps and 300Kbps to ensure we measured all possible scale levels (or encoded bandwidths)used for clip playouts.However,only 2sets of measurements,TCP for the entire playlist and UDP for the entire playlist,on the 35Kbps DSL-TBF con?guration is used to characterize the responsiveness of the RealVideo media scaling (see Section V-F).
IV.R ESULTS
Over the course of 2months,we streamed over a to-tal of 200hours of video from a cumulative total of over 4000video clips.Figure 2depicts a Cumulative Density Function (CDF)of the video playout lengths observed over all runs.The end time is recorded by subtracting the last time the end-host received packets from the start time of the clip.The median clip was about 3minutes,while the shortest and longest clip played out at 20seconds and 30minutes,respectively.
Of the original set of 100video clips,1clip could not be served by UDP,perhaps because of server ?rewall re-strictions.Also,21clips including the UDP restricted clip became completely unavailable after the initial selection.We removed these clips from further analysis.
Of the remaining 79clips in the playlist,about 30%
The queue was set to 5Kbytes for the 35Kbps DSL-TBF con?gu-ration.
00.20.4
0.60.81
010*******
400500600700800900
C u m u l a t i v e
D e n s i t y
RTT (milliseconds)
075 Kbps 150 Kbps 300 Kbps 600 Kbps
Fig.3.CDF of Ping Round Trip Time (All Runs)
0.2
0.4
0.6
0.8
1
00.05
0.1
0.150.2
C u m u l a t i v e
D e n s i t y
Loss (percent)
075 Kbps 150 Kbps 300 Kbps 600 Kbps
Fig.4.CDF of Ping Loss (All Runs)
of their servers did not respond to ping packets,mak-ing them unavailable for loss and round trip time (RTT)analysis.For all RTT and loss analysis in this Section and in Section V-B,Section V-C and Section V-E,we removed the data from these clips.Note,however,that we did use the other data recorded for other analysis.
Figure 3depicts a CDF of the average RTTs obtained via ping probes for each bottleneck bandwidth.The 75Kbps connection had the highest round-trip times.For the 150-600Kbps connections,about 33%of the clips had the same RTT regardless of the bottleneck bandwidth since these clips stream at less than 150Kbps,and therefore do not suffer additional queuing delays at the router.For the remaining 70%of the clips,the lower the bottleneck band-width the higher the queuing delays,caused primarily by the 10Kbytes buffer at the bottleneck router.
Figure 4depicts a CDF of the loss rates obtained via ping probes for each bottleneck bandwidth.About 37%of the clips played with low bottleneck bandwidths had no loss,while about 50%of the clips played at higher bottle-neck bandwidths had no loss.Overall loss rates increase about 0.1%as bottleneck bandwidths decrease from 600Kbps to 300Kbps to 150Kbps to 75Kbps.
Figure 5depicts a CDF of the packet size for all the
6
00.2
0.4
0.6
0.8
1
200
400
600
8001000
1200
1400
1600
C u m u l a t i v e
D e n s i t y
Packet Size (Kbytes)
TCP UDP
Fig.5.CDF of Packet Size (All Runs)
RealVideo clips over TCP and the RealVideo clips over UDP.In general,the TCP streams used larger packets than the UDP streams with a median UDP packet size of about 640Kbytes,and a median TCP packet size of about 1100Kbytes.Moreover,more than 30%of the TCP packets were equal to the typical network MTU,1500Bytes.A possible reason for the larger packet sizes over TCP is that while RealServers can control the application frame sizes to send,with TCP,those frames are often grouped and sent based on the current TCP window sizes.Although not shown in the graph,for the same bandwidth (in Kbps),the larger packets meant TCP streams sent fewer network packets than the UDP streams.
In order to provide background for the forthcoming analysis in Section V,we present two examples showing throughput versus time for a RealVideo stream over UDP going “head-to-head”with a RealVideo stream over TCP.Figure 6(top),shows an unconstrained network which allowed both UDP and TCP to stream as desired.During the ?rst part of each clip,both streams ?lled a delay buffer (as mentioned in Section V-D)at a higher data rate than the data playout rate.The UDP stream took an aggres-sive buffering approach,then slowly adapted to the net-work conditions.In contrast,the TCP stream more con-servatively increased the transmission rate during buffer-ing.Detailed analysis of RealVideo buffering over TCP and UDP is provided in Section V-D.
After the buffering phase,both UDP and TCP streamed at a steady,comparable playout rate since there was no congestion.The average bandwidth over the entire clip playout was relatively fair.Detailed analysis of RealVideo average bandwidth over TCP and UDP is provided in Sec-tion V-A.
During the playout phase,the bandwidth taken over 500ms intervals had about the same variance (was equally “smooth”)for both UDP and TCP.Detailed analysis of RealVideo smoothness over TCP and UDP is provided in
50
100
150
200
250
300
350
400
050
100150
200250
T h r o u g h p u t (K b p s )
Playout + Buffering Time (Seconds)
Clip-19 TCP (DSL: BW = 600Kbps, Q = 10Kbytes)Clip-19 UDP (DSL: BW = 600Kbps, Q = 10Kbytes)
100
200
300
400500
600
050
100150
200250
T h r o u g h p u t (K b p s )
Playout + Buffering Time (Seconds)
Clip-31 TCP (DSL: BW = 600Kbps, Q = 10Kbytes)Clip-31 UDP (DSL: BW = 600Kbps, Q = 10Kbytes)
Fig.6.Head-to-Head UDP versus TCP Streaming:FairPlayer
(top)and FoulPlayer (bottom)
Section V-G.
Figure 6(bottom),shows two video streams contend-ing for limited network bandwidth.During the ?rst part of each clip,UDP aggressively grabbed the available band-width,then slowly reduced its data rate as it encountered congestion.TCP,on the other hand,was severely lim-ited in bandwidth received until it slowly took up the bandwidth the UDP stream released.This unfairness in bandwidth persisted for nearly the entire clip,resulting in a lower average bandwidth for TCP than UDP.Detailed measurements of unfairness in average bandwidth for Re-alVideo over TCP versus UDP are provided in Section V-A,with analysis of TCP-Friendliness in Section V-E.Pos-sible reasons for bandwidth unfairness are provide in Sec-tion V-B and Section V-C.
At 30seconds,the TCP stream scaled its application layer data rate down to the lowest quality level (audio only),which allowed the UDP stream enough bandwidth room to scale up its quality level,creating an greater un-fairness.At 70seconds,the TCP stream increased its ap-plication data rate,causing the UDP stream to encounter congestion and decrease its application data rate.From 70to 130seconds,the average bandwidth for both streams was relatively fair.At 130seconds,the TCP stream again decreased its application data rate allowing the UDP
7 stream to twice increase its application data rate.How-
ever,for the?nal20seconds,the UDP stream scaled its
data rate down to match the TCP data rate,whereupon the
TCP stream scaled its data rate up to surpass that of UDP.
Detailed analysis of the behavior and role of application
level data rate scaling is provided in Section V-F.
V.A NALYSIS
In analyzing the responsiveness of RealVideo over UDP
compared with RealVideo over TCP,we?rst analyze band-
width aggregated over all clips and then compare head-to-head bandwidth use(Section V-A).Next,we explore correlations of bandwidth disparity with round-trip times (Section V-B)and loss rates(Section V-C).We then mea-sure the rate of initial buffering compared with the steady playout rate for both RealVideo over TCP and RealVideo over UDP(Section V-D).After that,we compare the band-widths of the TCP and UDP clips with a TCP-Friendly rate(Section V-E).We then move to the application layer where we analyze the application scaling capabilities(Sec-tion V-F).Lastly,we end with analysis of the smoothness of playout for RealVideo over UDP as compared with the smoothness of playout for RealVideo TCP(Section V-G).
A.Bandwidth
Figure7depicts CDFs of the average bandwidth used by TCP and UDP for each clip for bottleneck bandwidths of600,300,150and75Kbps.The TCP and UDP dis-tributions are nearly the same for the600Kbps bottle-neck bandwidths.However,as bandwidth becomes more constrained,the distributions separate,with UDP having a consistently higher distribution of bandwidths than TCP. We next analyze the head-to-head bandwidth for each pair of(TCP,UDP)clips.For each clip pair,in Figure8we plot an(,)point where is the average bandwidth used by the TCP stream and is the average bandwidth used by the UDP stream.The points for each bottleneck band-width are depicted by a different point style.The dashed 45degree line provides a reference for bandwidth equally shared by TCP and UDP.Points above the line indicate UDP received more average bandwidth while points below the line indicate TCP received more average bandwidth. The distance from the line indicates the magnitude of the average bandwidth difference.
From Figure8,while there are some points that lie along the equal bandwidth line,there are many cases of band-width disparity.The highest bandwidth playouts for the 600Kbps bottleneck bandwidths had the greatest band-width disparities.For the600Kbps bottleneck band-widths,there are visually as many points below the equal bandwidth line where TCP received more bandwidth as
50
100
150
200
250
300
350
400
050100150200250300350400 A
v
e
r
a
g
e
B
a
n
d
w
i
d
t
h
f
o
r
U
D
P
(
K
b
p
s
)
Average Bandwidth for TCP (Kbps)
75 Kbps
150 Kbps
300 Kbps
600 Kbps
Fig.8.Head-to-Head Average Bandwidth(All Runs)
there are above the equal bandwidth line where UDP re-ceived more bandwidth.For the lower bottleneck band-widths,there are visually considerably more points above the equal bandwidth line,indicating UDP received more bandwidth.
We next analyze the bandwidth disparity relative to the bottleneck bandwidth available.For each clip pair,we subtract the UDP average bandwidth from the TCP aver-age bandwidth and divide the difference by the bottleneck bandwidth.Thus,equal sharing of bandwidth has a value of zero,a value of-1indicates UDP got the entire bot-tleneck bandwidth,and a value of+1indicates TCP got the entire bottleneck bandwidth.Figure9depicts CDFs of the normalized bandwidth differences for each bottleneck bandwidth.
For the600Kbps bottleneck bandwidth,about40%of the clips shared the bandwidth equally.As indicated by the region in the top right,about30%of the TCP clips got more bandwidth than their counterpart UDP clips while about20%of the UDP clips got more bandwidth than their counterpart TCP clips,as indicated by the region in the bottom left.The greatest bandwidth disparity was approx-imately half the bottleneck bandwidth.
For the lower bottleneck bandwidths,there were in-creasingly fewer clips with equal bandwidth.The UDP clips got substantially more bandwidth than did their TCP counterparts,as indicated by the large areas under the dis-tributions on the bottom left.For the300Kbps bottle-neck bandwidth,about60%of the UDP clips got more bandwidth than their TCP counterparts,and for the150 Kbps and75Kbps bottleneck bandwidths,about70%of the UDP clips got more bandwidth than their TCP coun-terparts.For300,150and75Kbps bottleneck bandwidths, about20%of the UDP clips got twice the normalize band-width of their TCP counterparts.For150and75Kbps bottleneck bandwidths,about20%of the UDP clips re-ceived more than80%more of the bottleneck bandwidth
8
0.10.20.30.40.50.60.70.80.910100
200300400500600C u m u l a t i v e D e n s i t y
Average Bandwidth for 600 Kbps (Kbps)
Average Bandwidth for TCP Average Bandwidth for UDP
0.10.20.30.40.50.60.70.80.91050
100150200250300
C u m u l a t i v e
D e n s i t y
Average Bandwidth for 300 Kbps (Kbps)
Average Bandwidth for TCP Average Bandwidth for UDP
0.10.20.30.40.50.60.70.80.9102040
6080100
120140C u m u l a t i v e D e n s i t y
Average Bandwidth for 150 Kbps (Kbps)
Average Bandwidth for TCP Average Bandwidth for UDP
0.10.20.30.40.50.60.70.80.9101020
304050
6070
C u m u l a t i v e
D e n s i t y
Average Bandwidth for 75 Kbps (Kbps)
Average Bandwidth for TCP Average Bandwidth for UDP
Fig.7.CDFs of Average Bandwidth for Bottleneck Bandwidths of 600,300,150,and 75Kbps
0.2
0.4
0.6
0.8
1
-1
-0.8
-0.6-0.4-0.200.20.40.6
0.8
C u m u l a t i v e
D e n s i t y
Normalized Average Bandwidth Difference (TCP-UDP) (Kbps)
75 Kbps 150 Kbps 300 Kbps 600 Kbps
Fig.9.CDF of the Difference (TCP -UDP)in the Head-to-Head Average Bandwidth,Normalized by the Bottleneck Bandwidth (All Runs)
than their TCP counterparts.However,even for the low-est bottleneck bandwidths,there were still cases where the TCP clips got more bandwidth than their UDP counter-parts,as depicted by the areas above the distributions in the upper right.
In general,as bandwidth becomes more constrained,streaming RealVideo clips over UDP receive relatively more bandwidth than do streaming streaming RealVideo clips over TCP.
B.Round-Trip Time
We next analyze if bandwidth disparity increases with round-trip time.The data rate of TCP is paced by ac-knowledgments,so a higher round-trip time directly re-sults in a lower maximum throughput.The data rate of UDP,however,is not similarly constrained,suggesting that higher round-trip times may make the end-hosts slower to respond to congestion,thereby increasing the overall band-width used by UDP.
For each clip pair,we subtract the UDP average band-width from the TCP average bandwidth and graph the dif-ference versus the average RTT for that run.Figure 10depicts the difference versus RTT for all clips.The points below the horizontal zero line are runs in which the UDP clips got more bandwidth than their TCP counterparts,while the points above the horizontal zero line are runs in which the TCP clips got more bandwidth than their UDP counterparts.Visually,the UDP clips appear to have got-ten slightly more bandwidth as the RTTs get larger.The correlation coef?cient is -0.13.For reference,we also graph a least-squares line of the difference versus the RTT.We continue the round-trip time analysis in Figure 11which depicts the differences versus RTT for each bottle-neck bandwidth.For each bottleneck bandwidth,we graph a least-squares error line and compute the correlation co-
9
-150
-100-50050100
150
0200
4006008001000
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
RTT (milliseconds)
correlation -0.22
Fig.10.Head-to-Head Difference (TCP -UDP)in Average
Bandwidth vs.Round-Trip Time for All Bottleneck Band-widths
ef?cient.For 600Kbps,the correlation with bandwidth difference and RTT is very slight.However,when band-width becomes constrained,as in the cases of 300,150and 75Kbps bottleneck bandwidths,there was a modest corre-lation between bandwidth difference and RTT,with UDP having gotten increasingly more bandwidth than TCP as the round-trip times increased.
In general,as round-trip time increases,streaming Re-alVideo clips over UDP receive relatively more bandwidth than do streaming RealVideo clips over TCP for band-width constrained conditions.C.Loss
We next analyze if bandwidth disparity increases with loss rate.The data rate of TCP is typically halved with each loss event,so a higher loss rate directly results in a lower maximum throughput.The data rate of UDP,how-ever,is not similarly constrained,suggesting that higher loss rates may be ignored or downplayed,thereby increas-ing the overall bandwidth used by UDP.
For each clip pair,we subtract the UDP average band-width from the TCP average bandwidth and graph the dif-ference versus the loss rate for that run.Figure 12depicts the difference versus loss rate for all clips.Visually,the UDP clips appear to get only slightly more bandwidth as the loss rates increase.The correlation coef?cient is -0.03.For reference,we also graph a least-squares error line of the difference versus the loss rate.
We continue the round-trip time analysis in Figure 13which depicts the differences versus loss rate for each bot-tleneck bandwidth.For each bottleneck bandwidth,we graph a least-squares error line and compute the corre-lation coef?cient.For 600Kbps,there is no correlation with bandwidth difference and loss rate.However,for all other bandwidth constrained conditions,the correlations
-150
-100
-50
50
100150
00.020.040.06
0.08
0.10.120.14
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
Loss (percent)
correlation -0.03
Fig.12.Head-to-Head Difference (TCP -UDP)in Average
Bandwidth vs.Loss for All Bottleneck Bandwidths
between bandwidth difference and loss rate were moder-ate,with UDP having gotten increasingly more bandwidth than TCP as the loss rates increased.
In general,as loss rate increases,streaming RealVideo clips over UDP receive relatively more bandwidth than do streaming RealVideo clips over TCP for bandwidth con-strained conditions.D.Buffering Data Rate
As shown in the example at the end of Section IV,Re-alPlayer buffers data at an accelerated rate for the ?rst part of a clip.Analyzing the rate of this buffering rate versus steady playout rate may help to characterize the bursty na-ture of RealVideo streams.
The buffering rate was dif?cult to determine by look-ing at bandwidth during ?xed time periods,especially when TCP was contending for bandwidth.An aggressively buffering UDP stream often reduced the playout rate for the TCP stream for tens of seconds.After this time,the UDP stream might have ?nished buffering,allowing the TCP stream to increase its bandwidth to its normal buffer-ing rate.So,for each clip,we compute the maximum bandwidth averaged over 10second intervals taken over the ?rst 80seconds (calling this the buffering data rate )and compared this to the average bandwidth over the time from 100seconds until the clip ends (calling this the steady playout rate ).
Figure 14depicts the ratio of the average buffering data rate to the average steady playout rate for different steady playout rates.For reference,a ratio of 1indicates that the buffering data rate was equivalent to the steady playout rate.Low bandwidth clips buffered at up to 6times their average playout rate.Higher bandwidth clips buffered at relatively lower rates,possibly because total bandwidth re-strictions limited them from buffering at a higher rate.In order to determine if bandwidth restrictions limit
-150
-100-50050100
0200
4006008001000
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
RTT for 600 Kbps (milliseconds)
correlation 0.01
-150
-100
-50
50
1000200
4006008001000
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
RTT for 300 Kbps (milliseconds)
correlation -0.68
-150
-100-50050100
150
0200
400600
8001000
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
RTT for 075 Kbps (milliseconds) Polynomial Fit
correlation -0.64
-150
-100
-50
50
100
150
0200
4006008001000
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
RTT for 75 Kbps (milliseconds)
correlation -0.52
Fig.11.Head-to-Head Difference (TCP -UDP)in Average Bandwidth vs.Round-Trip Time for Bottleneck Bandwidths of 600,
300,150,and 75Kbps
1
2
3
4
5
6
7
050100
150200250300350400
A v e r a g e
B u f f e r i n g R a t e / A v e r a g e S t e a d y P l a y o u t R a t e
Average Steady Playout Rate (Kbps)
TCP (All DSL-TBF Runs)UDP (All DSL-TBF Runs)
Fig.14.Ratio of Average Buffering Rate to Average Steady
Playout Rate versus Average Steady Playout Rate (All DSL-TBF Runs)
buffering rates,we ran a set of experiments with the bot-tleneck bandwidth being the campus LAN attached to the Internet via a 15Mbps link 11.In this setup,the LAN envi-ronment was relatively unconstrained,having a bottleneck bandwidth which was typically at least three times that of our 600Kbps bottleneck bandwidth.
Figure 15depicts a CDF of the ratio of the average buffering data rate to the average steady playout rate.The
https://www.doczj.com/doc/8b11459329.html,/Admin/Netops/MRTG/
0.2
0.4
0.6
0.8
1
01
2345
67
C u m u l a t i v e
D e n s i t y
Average Buffering Rate / Average Steady Playout Rate
TCP (All LAN Runs)UDP (All LAN Runs)
Fig.15.CDF of Ratio of Average Buffering Rate to Average
Steady Playout Rate for LAN
buffering rate to steady rate for UDP was nearly the same as that of TCP for 40%of the clips.For 60%of the clips,however,the ratio of buffering rate to steady for UDP was signi?cantly higher than that of TCP.For UDP,the “steps”in the CDF are at typical bandwidth encoding rates,where the buffering rate was a ?xed multiple of these rates.For TCP,the steep slope in the CDF at around 2suggests TCP streams typically buffered at a rate twice that of the steady playout rate.
In general,both RealVideo clips over UDP and Re-
-150
-100-50050100
00.020.04
0.060.080.10.120.14
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
Loss for 600 Kbps (percent)
correlation -0.002
-150
-100
-50
50
10000.020.04
0.060.080.10.120.14
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
Loss for 300 Kbps (percent)
correlation -0.71
-150
-100-50050100
150
00.020.04
0.060.080.10.120.14
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
Loss for 150 Kbps (percent)
correlation -0.68
-150
-100
-50
50
100
150
00.020.04
0.060.080.10.120.14
A v e r a g e
B a n d w i d t h D i f f e r e n c e (T
C P -U
D P ) (K b p s )
Loss for 075 Kbps (percent)
correlation -0.49
Fig.13.Head-to-Head Difference (TCP -UDP)in Average Bandwidth vs.Loss for Bottleneck Bandwidths of 600,300,150,and
75Kbps
alVideo clips over TCP buffer data at a signi?cantly higher rate than the steady playout rate,suggesting that overall RealVideo traf?c is bursty.E.TCP-(Un)Friendly
Although RealVideo over UDP may receive a dispropor-tionate share of bandwidth versus their TCP counter parts,this may be because RealVideo TCP clips transmit at less than their maximum rate.A more serious test of unfair-ness is whether RealVideo over UDP is TCP-Friendly in that its data rate does not exceed the maximum arrival of a conformant TCP connection in the same circumstances.The TCP-Friendly rate,Bps,for a connection is given by [9]:
Bottleneck Un-Friendly Bandwidth TCP
75Kbps0(0%)
7(11%)
300Kbps0(0%)
4(6%)
28(11%)
13
50000
100000
150000
200000
250000
050100
150200
250300350C o d e d -B a n d w i d t h (b p s )
Playout + Buffereing Time (sec)
local bw limit (35 kbps)
Scale (Coded-BW) Movement for Clip-65 TCP Scale (Coded-BW) Movement for Clip-65 UDP
50000
100000
150000
200000
250000
300000
02040
6080
100120140
C o d e d -B a n d w i d t h (b p s )
Playout + Buffereing Time (sec)
local bw limit (35 kbps)
Scale (Coded-BW) Movement for Clip-78 TCP Scale (Coded-BW) Movement for Clip-78 UDP
Fig.18.Media Scaling Dynamics:Clip-65(top)and Clip-78
(bottom)(DSL:BW=35Kbps,Q=5Kbytes)
justing the application data rate to the network data rate is because TCP hides network information.RealPlayer over TCP can only measure application level goodput and not information on packet drop rates or network packet round trip times.RealPlayer over UDP,on the other hand,can more easily detect packet losses and measure round-trip times,allowing it to more quickly adjust the application data rate to the network rate.
Moreover,for high-quality videos not able to detect net-work congestion is critical.As evidenced by the TCP stream in the bottom graph of Figure 18,the server ?lls available TCP buffers with high quality video frames that must be delivered by the transport layer before it is able to scale down.For the user,this results in a large delay before frame playout begins as the high-quality frames are buffered over a low-bandwidth connection.Quantitatively,by looking at the end-time of transmission,the top graph of Figure 18shows that to play 3minutes of video,streaming over UDP took about 200seconds while streaming over TCP took more than 300seconds.In other words,stream-ing over UDP required 20seconds of buffering to play 3minutes of a video clip,while streaming over TCP required more than 2minutes of buffering to play the same clip.In Figure 19,the CDFs depict the number of media scale changes seen for each video clip,and summarize the rel-
0.1
0.20.3
0.40.50.60.7
0.80.9102
46
810
C u m u l a t i v e
D e n s i t y
Number of Scale (Coded-Bandwidth) Changes
Number of Scale Changes Seen for TCP Number of Scale Changes Seen for UDP
Fig.19.CDF of Media Scale Changes (DSL:BW=35Kbps,
Q=5Kbytes)
ative responsiveness of RealVideo to scale the application data rate to below the network bandwidth.Overall,UDP streams had more scale changes than did TCP streams.Also,Figure 19shows that about 20%(55%-35%)of the streams that scaled when streamed over UDP did not scale at all when streamed over TCP.
Figure 20summarizes the responsiveness of RealVideo media scaling based on how quickly the video stream adapted to the available bandwidth after streaming started.Speci?cally,we measure the time taken for the coded-bandwidth to drop under the inbound bandwidth limit,de-picted as the ?rst point under the 35Kbps limit for each stream in Figure 18.Figure 20shows that about 15%of video clips were low-quality and always required less than 35Kbps.Also,25%(40%-15%)of the video clips were able to adapt to the available bandwidth within a couple of seconds,independent of the transport protocol used.How-ever,for the remaining 60%of the clips,the TCP video streams took signi?cantly more time to adapt their scales to the available bandwidth.For example,80%of the UDP video streams adapted to the available bandwidth within 10seconds,while it took more than 25seconds for the same percentage of the TCP video streams to adapt.
In general,a signi?cant fraction of RealVideo clips are unable to adapt their application data rates to the avail-able network bandwidth,causing UDP streaming to be unfair under bandwidth constrained conditions.However,most RealVideo clips can,and do,scale their application data rates to the available network bandwidth.RealVideo streams over UDP can adjust their application data rate to the available bandwidth more ef?ciently than can Re-alVideo over TCP.G.Smoothness
Streaming media has more strict timing constraints than does traditional media.Streaming video requires not only
14
0.10.20.30.40.50.60.70.80.91010
20304050607080
C u m u l a t i v e
D e n s i t y
Elaps Time in Seconds: 0 to time(Coded-BW < 35kbps)
Scale Adaptation Speed for TCP Scale Adaptation Speed for UDP
Fig.20.CDF of Media Scale Adaptation Speed (DSL:BW=35
Kbps,Q=5Kbytes)
a moderate to high bandwidth but also a smooth data rate.TCP’s acknowledgment based window advancement can result in a bursty data rate,especially for high round-trip times.Streaming media applications often cite these rea-sons in choosing UDP as a transport protocol.
For each clip,we calculate the “smoothness”of the net-work data rate by taking the ratio of consecutive band-widths measured over 500ms intervals.For example,if the data rate is 200Kbps for one time interval and 400Kbps the next time interval,the smoothness would be 2.If the data rate then dropped by half back to 200Kbps,it would be 0.5.Figure 21depicts CDFs of smoothness for each network bottleneck bandwidth.Both TCP and UDP were smooth for a bottleneck of 600Kbps.With bottle-neck bandwidths of 300,150and 75Kbps,both TCP and UDP became noticeably less smooth,with TCP often far less smooth than UDP.
In general,streaming RealVideo clips over UDP receive a smoother playout rate than do streaming streaming Re-alVideo clips over TCP for bandwidth constrained condi-tions.
VI.D ISCUSSION
OF
R ESULTS
In the current Internet,there are no concrete incentives for applications that use UDP to initiate end-to-end con-gestion control.In fact,at the network level,unresponsive applications may be “rewarded”by receiving more than their fair share of link bandwidth.As seen in Section V,streaming media over UDP can result in a higher average bandwidth rate than streaming media over TCP,primarily because competing TCP sources are forced to transmit at a reduced rate.Plus,as seen in Section V-F,it is more dif-?cult for the application layer to adjust the encoding rate to the available bandwidth when using TCP (because there is no API that gives you available bandwidth,for exam-ple).Lastly,as seen in Section V-G UDP often provides
a smoother media playout rate than TCP.Thus,there are strong application-oriented reasons for streaming media to use UDP rather than TCP,suggesting potentially high-bandwidth video over UDP may contribute to congestion collapse.
However,given the current climate where end-to-end congestion control,and even TCP-Friendly congestion control,is fundamentally important to the well-being of the Internet,there are likely social pressures for video software designers not to release products without some form of end-to-end congestion control.Moreover,an un-responsive “?re-hose”application,such as high quality video over a congested link,is ineffective from the ap-plication standpoint primarily because having a congested router randomly drop packets can cause more important data packets to be dropped.Instead,applications can sig-ni?cantly bene?t by using media scaling,as illustrated by RealPlayer in Section V-F to make intelligent decisions about which packets not to send beforehand,making low quality video over the same congested link quite effec-tive.Anecdotally,in our pilot tests with severe congestion,older versions of RealPlayer would continue to attempt to stream video,inducing even more congestion,while newer versions of RealPlayer would terminate the connection un-der the same conditions.Moreover,as shown in Section V-F,RealVideo over UDP clearly scales the application data rate to meet the available bandwidth.Thus,while it is not clear as to exactly what degree practical or social incen-tives are effective,they may be having a signi?cant impact.The higher buffering rate seen in Section V-D is ben-e?cial for users,but possibly harmful to the network.A higher buffering rate either allows the player to build up a larger buffer before beginning frame playback and thus better avoiding any unsmoothness caused by network jit-ter or transient congestion,or allows the frame playback to begin earlier.However,the increased buffering rate makes the streaming traf?c more bursty and,with UDP,it can cause even more unfairness versus other TCP ?ows.Overall,from the network point of view,the buffering rate should be limited to the playout rate.
VII.C ONCLUSIONS
The decreasing cost of powerful PCs and the increase in video content on the Web is fueling the growth of stream-ing video over the Internet.Unlike traditional applications,streaming video often uses UDP as a transport protocol rather than TCP,suggesting that streaming video may not be TCP-friendly or that streaming video may be unrespon-sive to network congestion.Since congestion control is fundamentally important to the health of the Internet,a better understanding of streaming video using UDP ver-
15
0.10.20.30.40.50.60.7
0.80.911/2
1
2C u m u l a t i v e D e n s i t y
Throughput Ratio for 600 Kbps
TCP UDP
0.10.20.30.40.50.60.7
0.80.911/2
1
2C u m u l a t i v e D e n s i t y
Throughput Ratio for 300 Kbps
TCP UDP
0.10.20.30.40.50.60.7
0.80.911/2
1
2C u m u l a t i v e D e n s i t y
Throughput Ratio for 150 Kbps
TCP UDP
0.10.20.30.40.50.60.7
0.80.911/2
1
2
C u m u l a t i v e
D e n s i t y
Throughput Ratio for 75 Kbps
TCP UDP
Fig.21.Smoothness Ratio for Bottleneck Bandwidths of 600,300,150,and 75Kbps
sus TCP can help focus network layer research that detects and polices unresponsive ?ows,or transport layer research that develops better streaming protocols.
Commercial streaming video players,such as RealNet-works’RealPlayer,promise to have a large in?uence on the impact of streaming video on the Internet.While pre-vious empirical studies have focused on Internet traf?c in general or have concentrated on overall measurements of streaming applications,to the best of our knowledge,there have been no detailed studies on the responsiveness to con-gestion of commercial players streaming over UDP rela-tive to TCP.
In this work,we do “head-to-head”network perfor-mance comparisons of RealVideo streaming over UDP with RealVideo streaming over TCP.We set up a testbed that allows us to simultaneously stream two RealVideo clips,one over TCP and one over UDP,along the same network path.Our testbed also lets us control the net-work bottleneck bandwidth,thus allowing us to compare the responsiveness to congestion of the UDP and the TCP https://www.doczj.com/doc/8b11459329.html,ing our testbed,we stream over 1000video clips with a variety of content and encoding bandwidths selected from across the Internet.
Overall,we ?nd there are many incentives for Re-alVideo streams to use UDP versus TCP,including higher average bandwidth during congestion,smoother playout rate during congestion and more ef?cient application layer media scaling.
RealVideo over UDP typically receives the same band-width as that of RealVideo over TCP.Even during periods of packet loss,most RealVideo over UDP is TCP-Friendly.However,under constrained bandwidth conditions,Re-alVideo over UDP can get substantially more bandwidth than RealVideo over TCP.The bandwidth use gets increas-ingly unfair with an increase in packet loss rate and round-trip time.
Most RealServers can,and often do,scale the applica-
tion layer data rate in an attempt to match the network data rate.Application scaling tends to be coarser at higher lev-els of bandwidth but is often ?ne grained at lower levels of bandwidth.While application scaling can be an effec-tive means of responding to congestion,about 35%of Re-alVideos cannot do application scaling at all.Adjusting the application data rate to the network bandwidth is more dif-?cult when streaming over TCP versus UDP,most likely because TCP streams do not have as much information about the current network state as do the UDP streams.RealPlayers typically buffer video data for up to 40sec-onds at a much higher rate than the average playout rate.While bene?cial to the user,this initial burst of traf?c can cause considerable congestion and probably makes Re-alVideo network traf?c more dif?cult to manage.
When bandwidth is constrained,RealVideo streams over UDP typically playout at a smoother rate than Re-alVideo streams over TCP.However,both TCP and UDP streams are equally smooth when there is no contention for bandwidth.
VIII.F UTURE W ORK
This work is only another step in the analysis of stream-ing multimedia traf?c on the Internet,leaving many areas for future work.
The major commercial competitor to RealNetworks’RealPlayer is Microsoft’s Windows Media Player.A “head-to-head”performance comparison of MediaPlayer streaming over UDP might be bene?cial to understand the differences in responsiveness across commercial players.We intentionally selected pre-recorded video clips to help ensure consistency in the videos played out during each set of experiments.Live content,captured and served directly from a video camera or television,typically has different characteristics than does pre-recorded content.Future work could be to measure the performance of live RealVideo content on the Internet and compare it to that of
16
the pre-recorded RealVideo content in our study.
The work in this paper did not explore the relationship between perceptual quality of the video,in?uenced by ap-plication level metrics such as frame rate and jitter,and network metrics.A better understanding of the impact on perceptual quality on video streaming over UDP versus TCP might further aid in developing more effective ways to use a TCP-Friendly share of bandwidth.
R EFERENCES
[1]Real Networks Incorporated,“RealNetworks Facts,”2001,URL:
https://www.doczj.com/doc/8b11459329.html,/gcompany/index.html.
[2]Rezza Rejaie,Mark Handley,and D.Estrin,“RAP:An End-
to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet,”in Proceedings of IEEE Infocom,1999.
[3]Sally Floyd,Mark Handley,Jitendra Padhye,and Jorg Widmer,
“Equation-Based Congestion Control for Unicast Applications,”
in Proceedings of ACM SIGCOMM Conference,2000,pp.45–
58.
[4]Joerg Widmer,Martin Mauve,and Jan Peter Damm,“Probabilis-
tic Congestion Control for Non-Adaptable Flows,”in Proceed-ings of NOSSDAV,May2002.
[5]J-C.Bolot,S.Fosse-Parisis,and D.Towsley,“Adaptive FEC-
Based Error Control for Internet Telephony,”in Proceedings of IEEE INFOCOM,Mar.1999.
[6]Yanlin Liu and Mark Claypool,“Using Redundancy to Re-
pair Video Damaged by Network Data Loss,”in Proceed-ings of IS&T/SPIE/ACM Multimedia Computing and Networking (MMCN),Jan.25-272000.
[7] C.Padhye,K.Christensen,and W.Moreno,“A New Adaptive
FEC Loss Control Algorithm for V oice Over IP Applications,”in Proceedings of IEEE International Performance,Computing and Communication Conference,Feb.2000.
[8]K.Park and W.Wang,“QoS-Sensitive Transport of Real-Time
MPEG Video Using Adaptive Forward Error Correction,”in Pro-ceedings of IEEE Multimedia Systems,June1999,pp.426–432.
[9]Sally Floyd and Kevin Fall,“Promoting the Use of End-to-End
Congestion Control in the Internet,”IEEE/ACM Transactions on Networking,Feb.1999.
[10]R.Mahajan,S.Floyd,and D.Wetherall,“Controlling High-
Bandwidth Flows at the Congested Routers,”in In Proceedings of the9th International Conference on Network Protocols(ICNP), Nov.2001.
[11]Ion Stoica,Scott Shenker,and Hui Zhang,“Core-Stateless Fair
Queueing:Achieving Approximately Fair Bandwidth Allocations in High Speed Networks,”in Proceedings of ACM SIGCOMM Conference,Sept.1998.
[12]W.Feng,D.Kandlur,D.Saha,and K.Shin,“Stochastic Fair
Blue:A Queue Management Algorithm for Enforcing Fairness,”
in Proceedings of IEEE INFOCOM,Apr.2001.
[13] D.Lin and R.Morris,“Dynamics of Random Early Detection,”
in Proceedings of ACM SIGCOMM Conference,Sept.1997. [14]Debasis Mitra,Keith Stanley,Rong Pan,Balaji Prabhakar,and
Konstantinos Psounis,“CHOKE,A Stateless Active Queue Man-agement Scheme for Approximating Fair Bandwidth Allocation,”
in Proceedings of IEEE INFOCOMM,Mar.2000.
[15] A.Clerget and W.Dabbous,“Tag-based Uni?ed Fairness,”in
Proceedings of IEEE INFOCOM,Apr.2001.
[16]Z.Cao,Z.Wang,and E.Zegura,“Rainbow Fair Queuing:Fair
Bandwidth Sharing Without Per-Flow State,”in Proceedings of IEEE INFOCOMM,Mar.2000.
[17]Art Mena and John Heidemann,“An Empirical Study of Real Au-
dio Traf?c,”in In Proceedings of the IEEE Infocom,Mar.2000, pp.101–110.
[18]Jupiter Media Metrix,“Users of Media Player Applications In-
creased33Percent Since Last Year,”Apr.2001,Press Release.
https://www.doczj.com/doc/8b11459329.html,/company/pressrelease-.jsp?doc=pr01040. [19]Yubing Wang,Mark Claypool,and Zheng Zuo,“An Empirical
Study of RealVideo Performance Across the Internet,”in Pro-ceedings of the ACM SIGCOMM Internet Measurement Work-shop,Nov.2001.
[20]Real Networks Incorporated,“RealPlayer8User Man-
ual,”copyright2000,URL:https://www.doczj.com/doc/8b11459329.html,/help/player-/plus
小学六年级数学毕业测试题 一、填空。（28分。） 1、据统计，我国汉族人口是十一亿三千七百三十九万人，写作（ ），省略“亿”后面的尾数约是（ ）人。 2、 5时24分＝（ ）时 8050平方米＝（ ）公顷 3456立方厘米＝（ ）升 3千克50克=（ ）千克 3、填上合适的单位名称： 一个水桶高约4（ ） 数学书的封面面积约为360（ ） 一袋大米约重25（ ） 喝水杯的的容积250（ ） 4、（ ）/10=（ ）:45=6÷（ ）=2/5 5、一个三角形三个内角的度数比是5:3:1,这个三角形最大的角是（ ）度，这个三角形是（ ）三角形 6、一台收音机原价100元，先提价10％，又降价10％，现在售价是（ ）元。 7、经过两点可以画出（ ）条直线，两条直线相交有（ ）个交点。 8、找规律： （1）4、 9、16、（ ）、36、49。 （2）1/2、2/4、（ ）4/8、( )。 9、把3米长的绳子平均分成5段，每段占全长的（ ），是（ ）米。 10、等底等高的圆柱和圆锥体积之差是4.6立方分米，圆柱的体积是（ ）立方分米。 11、鸡兔同笼，共有30个头，88只脚。求笼中鸡（ ）只，兔有（ ）只。 12、在一个口袋里有2个红球和8个黄球，从中任意摸出1个球，摸出红球的可能性是（ ），如果摸10000次，摸出红球的可能性是（ ）次。 二、选择。（10分。） 1、长方体体积一定，底面积和高（ ） ①成正比例；②成反比例；③不成比例；④既可能成批比例，又可能成正比例。 2、下列图形中对称轴最多的是（ ） ① 长方形； ② 正方形； ③ 三角形； ④ 圆。 3、一个长方形框架拉成平行四边形后，面积（ ）。 ①不变； ②减小； ③增大； ④既可能减小又可能增大。 4、一个长方形、一个正方形和一个圆的周长相等，那么面积最大的是（ ） ① 长方形 ② 正方形 ③ 圆 5、要反映小红六年级数学成绩变化情况，应选择（ ） ①条形统计图 ②折线统计图 ③扇形统计图 三、计算。（28分） 1、直接写出得数（8分） 24.06＋0.4= ( 5165-)×30= =+5 3 73 12.5×32×2.5= 121÷6= 5－（9792+）= 5 4×25= 2.8×25＋12×2.5= ２、脱式计算，能简算的要写出简算过程。（18分） 85.87－(5.87+2.9) 1.25×7×0.8 54.2－2/9＋4.8－ 19 7 125)731(35÷-? 1387131287÷+? 11 8 )26134156(?-? 3．求未知数x 6/7x ＋4.8＝5 χ－3/5 χ= 6/5 0.8x+1.2x ＝25 四、操作题 （6分） 1、把三角形向右移动5格； 2、把三角形绕B 点逆时针旋转900 , 3、把三角形按2:1的比放大。 （3分） 2、在下图上完成下列问题。（3分） （1）科技馆在学校北偏东30°方向2000米处。请在图中标出科技馆的位置，并标出数据。 （2）南京路经过电影院，与上海路平行。请用直线标出南京路的位置。
北师大版小学数学六年级（上册）知识点 第一单元圆 1、使学生认识圆的特征：圆的半径、直径、圆心。认识在同圆内半径和直径的关系。知道圆是轴对称图形，有无数条对称轴，而这些对称轴都过圆心。知道生活中有了圆才使我们的生活更美好。 2、认识同心圆、等圆。知道圆的位置由圆心决定，圆的大小由半径或直径决定。等圆的半径相等，位置不同；而同心圆的半径不同，位置相同。 3、使学生知道圆的周长和圆周率的含义，掌握圆的周长的计算公式，能够正确地计算圆的周长．介绍祖冲之在圆周率研究上的成就，渗透爱国主义教育。在运用上，要能根据圆的周长算直径或半径，会算半圆的周长：圆的周长×1/2+直径。会求组合图形的周长。 4、了解圆的面积的含义，经历圆面积计算公式的推导过程，掌握圆面积计算公式。 5、能正确运用圆的面积公式计算圆的面积，并能运用圆面积知识解决一些简单实际的问题。会灵活运用圆的面积公式。已知圆的周长会算圆的面积，会求组合图形的面积。会算圆环的面积，并且知道在周长相等的情况下，正方形、长方形、圆三种图形中，圆的面积最大。 6、在估一估和探究圆面积公式的活动中，体会“化曲为直”的思想，初步感受极限思想。 第二单元百分数的应用 本单元重点讲解百分数在生活中的应用，知识点为： 1、知道百分数的意义：表示一个数是另一个数的百分之几的数，叫做百分数。百分数也叫做百分率或百分比。百分数通常不写成分数形式，而用百分号“%”
表示；百分数有时也定义为分母是100的分数，但百分数与分数是有区别的：分数既可表示具体的量，又可表示两个数量间的倍比关系；然而百分数只能表示两个数量间的倍比关系；所以是不名数，也就是不能带单位的数。 2、在具体情景中理解“增加百分之几”或“减少百分之几”的意义，加深对百分数意义的理解。 3、能解决有关“增加百分之几”或“减少百分之几”的实际问题，提高运用数学解决实际问题的能力，体会百分数与现实生活的密切联系。 4、知道出勤率、出粉率、成活率等百分数的意义及在实际生活中的应用，会计算这种百分数。 5、知道成数、打折的含义。表示一个数是另一个数十分之几、百分之几的数，叫做成数。打折就是按原价的百分之几十、十分之几出售。八五折就是按原价的85%出售。成数和折扣数不能用小数表示。 6、能解决“比一个数增加百分之几的数是多少”或“比一个数减少百分之几的数是多少”的实际问题。 7、进一步加强对百分数的意义的理解，并能根据百分数的意义列方程解决实际问题，会解含有百分数的方程。 8、能利用百分数的有关知识，解决一些与储蓄有关的实际问题，提高解决实际问题的能力。知道利息是本金存入银行过一段时间取出后多出来的钱；本金是存入银行的钱；利率就是某段时间中利息占本金的百分比；利息税是国家银行规定的针对利息收入的税收。会计算利息。利息=本金×利率×时间 9、结合储蓄等活动，学习合理理财，逐步养成不乱花钱的好习惯。 第三单元图形的变换 1、通过观察、操作、想象，知道一个简单图形是怎样经过平移或旋转制作复杂图形的过程，体验图形的变换，发展空间观念。并能借助方格纸上的操作和分析，有条理地表达图形的平移或旋转的变换过程。
上网下了巨多电影，可是坐在电脑前看电影真的不是一件很舒服的事，电脑显示屏幕小（我的是15液晶），而且坐时间长了腰酸背痛，远没有躺在床上或者沙发上看电视舒服。于是我设想，如果把电脑视频信号传送到电视上，躺着看电影该有多好！ 心动不如行动，我马上行动起来，经过一番上网调查研究和实践，终于实现了躺着看电影的想法。如果您也有兴趣，下面我就把具体过程说一说，有兴趣的朋友不妨一试。 一、检查硬件配置 首先要确认显示卡上是否具有S端子。目前绝大多数带独立显卡的电脑都有TV-Out功能，大多由S端子实现，一般标示为TV-Out、S-Video或VID-Out。网上说，目前有些显示卡采用的为非标准5Pin的S端子，经测试也可以使用标准5Pin的S端子线。我的电脑用的是GeForce FX 5200 128M显示卡，具有标准的5Pin S端子。 再者要确认电视机是否具有视频输入（Video-In）接口或S端子接口。除了一些较老的电视，都具有这两种接口，只要具有其中一种就可以实现视频信号的输入。我的电视为04年购买的创维21英寸健康数字彩电（很普通的纯平），只有Video-In接口，没有s端口。 二、购买有关转接线线 依照现有条件，我去了趟辽宁路信息城，卖电脑配件耗材的在负一层，随便找个摊位就能购置齐全：第一步：购买S端子→莲花头转接线1根，长约1.5米，售价5元。电视距离电脑机箱远的，可以买相应莲花转接头用双股视频线自己做一根连接线，大家可根据电视与计算机之间的距离酌情购买，电线长度从2米至50米都有，一般为2元1米左右，很便宜。 第二步，标准音频插头→莲花头转接线1根，长约1.5米，售价3元，砍价到2元！ 如果你的电视具有S端子，那更简单了，直接购买两头均为S端子的延长线。 以上花费为：2元车费+7元转接线费用，共9元。买完后感觉花的太少，顺便花了25元买了一块usb 2.0插卡，俺家电脑主板不支持usb2.0，只能自己改装了！ 三、线路连接 连接起来比较简单，只需要将S端子→莲花头转接线的S端子接入显示卡，莲花头一端插入电视机后面视频输入（Video-In）端，然后将标准音频插头→莲花头转接线的标音插头端插入计算机声卡的声音输出接口，将莲花头接入电视机的音频输入接口，这一步骤很简单，如同连接电视机与dvd机一样，很简单，5分钟搞定。 四、软件设置 接下来，打开电脑，软件设置前请将电视打开，并置于AV频道上，如果不这样做驱动程序将检测不到电视，有可能会看不到需要设置的选项。依次进入显示属性→设置→高级→显示卡页面，然后点击左侧的nView选项，nView模式默认为“单一显示器”，将其在下拉式菜单中更改为“复制”，下面的显示器选项为“模拟显示器+电视”，设置“模拟显示器”为主显示屏，电视的制式PAL-D不用修改，点击确定。这时电视上将会出现与显示器一模一样的信号了！ 这样,俺就可以用电脑播放电影，躺在床上用电视看了！ 但是显示器和电视上的信号是一样的，这样看电影的时候别人就不能再使用计算机了，有没有什么方法可以让使用计算机和看电影两不耽误呢？答案是肯定的，只要再次进入显示卡的设置，看到左侧选项中有一项是“全屏幕视频”了吗，这个选项在不连接电视时是看不到的，只有连接电视设置为“复制”模式后这个选项才会出现。点击“全屏幕视频”选项，下面有“全屏视频控制”项，默认值是“禁止”，将其更改为“辅助显示器”，然后确认退出。这时再播放一个视频文件试一下，你会发现，无论是使用RealPl ayer、Media Player还是金山影霸播放视频文件，电视上都会自动全屏播放，不再与显示器同步了，计算机方面还可照常进行其***作。如设置为“复制”模式后，播放DVD、VCD时电视显示正常，可是播放AVI、
六年级数学下册（北师大版）总复习综合练习题 班别：姓名：评分：等级： 一、填空题。（每空1分，共24分） 1、由3个十万，4个千组成的数写作（），改写成“万”为单位是 （）。 2、3时45分=（）时 3.08升（）毫升 3、1 2 千米：8米化成最简整数比是（），比值是（）。 4、某地早晨气温－5℃，中午气温6℃，从早晨到中午气温上升了（）℃。 5、60千克是40千克的（）%，1米的3 5 和（）米的20%一样长。 6、把4米长的铁丝平均截成8段，每段是这根铁丝的（） （） ，每段长（）米。 7、36和48的最大公因数是（），最小公倍数是（）。 8、在一张长是8分米，宽6分米的长方形卡纸中，剪一个面积最大的圆，这个圆的面积 是（）平方分米。 9、一幅地图的比例尺是1：500000，表示实际距离是图上距离的（）倍，在这幅地 图上量得甲、乙两地相距8.8厘米，甲、乙两地间的实际距离是（）千米。 10、在24、22、20、26、26、26、这组数据中，中位数是（），众数是（）， 平均数是（）。 11、等底等高的圆柱与圆锥的体积总和是60立方米，那么圆柱的体积是（）立方米， 圆锥的体积是（）立方米。 12、4根小棒长分别是2厘米，3厘米、5厘米，7厘米，选其中的三根，围成一个三角形， 三角形的周长是（）厘米。 13、摆一个三角形需要3根小棒，摆两个三角形需要5根，摆3个三角形需要（） 根小棒，摆m个三角形需要（）根小棒。 二、判断题（正确的在括号里打“√”，错的打“×”）。(5分) 1、0.8和0.80的大小相等，计数单位也一样。（） 2、圆的面积和它的半径成正比例。（） 3、师徒两人共同生产一批零件，徒弟生产的零件合格率是90%，那么师傅生产的零件合 格率是110%。（）
八种视频格式转换详解 常见的视频格式有很多，如果你稍微了解一点儿视频知识，就应该不会对诸如A VI、MPEG、MOV、RM等常见视频格式感到陌生。兵来将挡，水来土掩。什么格式的文件就有什么样的播放器对应：MOV 格式文件用QuickTime播放，RM格式的文件当然用RealPlayer播放。但假如你的爱机中只装有RealPlayer播放器，而你所得到的却是一个MOV格式文件，此时你跟谁急都没用。最好的办法就是要找到这两种视频格式之间的“桥梁”从而实现互相转换，你也就可以美滋滋地欣赏精彩的视频文件了。 A VI→MPEG(MPEG－1) A VI和MPEG应该是很常见的视频格式了，所以格式转换的软件颇多，有bbMPEG 1.23、Honestech MPEG Encoder 1.1、TMPGEnc beta 12a等等。这里我们介绍的是Honestech MPEG Encoder 1.1，它能够帮你把A VI视频文件转换成MPEG视频文件的软件，由于使用了一种特殊的编码算法，使得转换文件的工作能够更快速、准确地完成。虽然编码特殊，但你大可不必担心操作步骤过于复杂，因为该软件有着简单的操作界面，只要选择想要转换的A VI 视频文件，接着设置转换文件的存档名称和保存路径，即可以开始转换文件。另外推荐的是Panasonic MPEG1 Encoder 2.51，这是日本松下公司所研制的A VI 转换MPEG－1软件，如果你有纪念性的家庭录影带，可以事先转换
成A VI格式，再用此套软件将它转换成MPEG－1格式，然后用刻录器将MPEG－1格式文件刻录光盘片，得到的就是普通的VCD光盘了，可以拿到任何VCD播放器上播放。 MPEG(MPEG－1)→A VI 常用的软件有Honestech MPEG Recoder 1.0、VCDGear (GUI) 2.0 Final 等等。这里推荐使用的软件是Honestech MPEG Recoder 1.0，因为它可以在播放影像文件的时候记录和捕捉活动的图像数据，而且在保证高质量的情况下实现从MPEG到A VI文件之间的转换，为磁盘节省了不少空间。如果你要求稍高一点，可以试用一下VCDGear，它在从VCD中转换出MPEG影像时可以修正MPEG中含有的错误。 MPEG(MPEG－1)→ASF 要将MPEG－1格式的影像文件转换成微软的ASF视频流格式文件，所需要的软件工具有：Sonic Foundry Stream Anywhere、Windows Media Toolkit等等。因为需要ASF压缩编码驱动库的支持，首先必须安装Windows Media Toolkit。然后运行Sonic Foundry Stream Anywhere，从中打开你的MPEG文件，将之另存为ASF文件就可以了。注意设置一下生成ASF的参数，最佳的是在320×240和30帧/秒的情况下。
最新北师大版小学六年级数学毕业试卷 姓名____________ 得分____________ 一、填空。（22分） l.一个数的亿位上是5、万级和个级的最高位上也是5，其余数位上都是0，这个数写作（），省略万位后面的尾数是（） 2、2小时15分=（）小时 4.2吨=（）千克 3、篮球个数是足球的125％，篮球比足球多（）％。 4、6÷15＝（ )/45＝（）％＝24÷（）＝＿＿＿＿（填小数）。 5、一个圆锥的体积是76立方厘米，底面积是19平方厘米。这个圆锥的高是（）厘米。 6、把化成最简整数比是( )，比值是( )。 7、一个直角三角形中，两个锐角度数的比是3 : 2 ,这两个锐角分别是（）度、（）度。 8、12的因数中可以选出4个数组成一个比例，请你写出比值不同的两组：（）。 9、甲乙的比为5：4，甲数比乙数多（）％，乙数又比甲数少（）％。 10、比a的3倍多1.8的数，用含有字母的式子表示是（），当a=2.4时，这个式子的值是（）。 11、投掷100次硬币，有48次正面向上，那么投掷第101次硬币正面向上的可能性是（） 12、一根长2米的直圆柱木料，横着截去2分米，和原来比，剩下的圆柱体木料的表面积减少12.56平方分米，原来圆柱体木料的底面积是（）平方分米，体积是（）立方分米。 二、判断（ 7分）
1、圆锥体的底面半径扩大3倍，高不变，体积也扩大3倍。（） 2、在比例里，如果两个内项的乘积是1，那么，组成比例外项的两个数一定互为倒数。（） 3、有10张卡片，上面分别写着1——10这些数。任意摸出一张，摸到偶数的可能性是1/5。（） 4、如果4a=3b，那么a ：b = 4 ：3。（） 5、从学校走到电影院，甲用了10分钟，乙用了12分钟。甲和乙每分钟所走的路程的最简整数比是5∶6。 ( ) 6、两个相邻的非零自然数一定是互质数。( ) 7、生产的90个零件中，有10个是废品，合格率是90%。（） 三、选择。( 7分 ) 1、某班女生人数的4/7 等于男生人数的2/3，那么男生人数（）女生人数． A．小于B．大于C．等于 2、某产品降价前售价是150元，降价后售价是120元，降低了( )。 A. 20％ B. 25％ C. 80％ D. 75％] 3、下列三句话中，正确的是（） A．一种商品打八折出售正好保本，则不打折时该商品只获20%的利润 B．三角形中最大的角不少于60度 C．分母能被2和5整除的分数一定能化成有限小数 4、两根2米长的铁丝，第一根截去它的3/4，第二根截去3/4 米。余下部分( )。 A、长度相等 B、第一根长 C、第二根长 5、用三根同样长的绳子，分别围成一个长方形、正方形和圆形，面积最大的是（）。
9.2 RealPlayer播放软件 1．为何无法播放Rmvb格式的电影 【分析故障】根据现象分析，可能是编码器损坏。 【问题处理】将Real player卸载，然后重新安装即可。 2．为何无法播放某些DVD光盘 【分析故障】主要是因为mpeg2格式的解码器是有版权的，没有捆绑在RealPlayer里面。 【问题处理】可以上网下载第三方的解码器（如Divx5插件），解决这个问题。 3．播放电影时出现两种声音怎么办 【分析故障】 RealPlayer本身不带调节声道的功能，但可以使用系统的声音属性来调节。 【问题处理】如果RM文件在制作时未将音频格式设置为立体声音乐，除非将一个音箱的连接去除，否则没有别的办法。而如果是立体声音频，则可以在Windows系统中调节，方法是双击任务栏右侧的小喇叭图标，在打开的对话框中将声道控制滑块向左或向右拉即可。 4．为何无法播放AVI影片 【分析故障】这是由于没有安装相关的插件造成。 【问题处理】上网下载相关插件（如ffdshow）后，问题解决。 5．为何用RealOne无法在线看电影 停止响应。 【分析故障】可能是由于系统中存在与RealOne冲突的程序，如超级解霸播放器。 【问题处理】将其他播放器（如超级解霸播放器）卸载，然后重新安装RealOne，故障排除。6．如何取消播放历史记录 不希望下次程序自动保留播放记录，可以取消选择“允许在文件菜单中显示历史记录列表”复选框。 7．为何播放时字幕不同步 【分析故障】通常是由于字幕的FPS（每秒中填充图像的帧数）和影片的FPS不符造成的。 【问题处理】调整字幕的FPS或利用Vobsub程序组中的“SubResync”调整字幕的延时、时间码和速率即可。 8．为何拖动播放RMVB文件时死机 【故障现象】在用RealPlayer播放一个RMVB文件时，一拖动却造成了死机 【分析故障】这一般是因为媒体文件头损坏造成的。 【问题处理】用“RM电影修复专家”能快速修复无法拖动播放进度的RM电影。安装上“RM电影修复
新北师大版小学六年级数学下册总复习教案
20、图形的认识（一）线与角 学习目标： 1、系统整理学过的图形，沟通各种图形之间的联系。 2、可以结合具体情境认识各种角。 学习重点：建立知识之间的网络图，结合具体情境理解线与角。 学习难点：根据平面的基本特征，能够理解平面图形相互之间的联系。 学习准备：多媒体。 教学过程： 一、自主尝试： 1、我们学过哪些图形？ 2、学过哪些角？ 二、合作探究： 1、用自己喜欢的方式展示你学过的图形，并对它们进行分类。介绍整理的方法，培养学生整理知识的能力。 2、直线、射线、线段的特征各是什么？学生可以动手操作。 3、平行线和垂线的特征是什么？ 4、角的概念，角的分类，角的大小与什么有关？让学生画一画，进行交流。 三、汇报点评： 1、直线没有端点，射线有一个端点，线段有两个端点。 2、在同一个平面内，两条直线的相互位置是平行或相交。两条直线相交成直角这两条直线叫做垂直；在同一平面内不相交的两条直线叫平行。 四、巩固练习：
下面图形中，有几组平行线？有几条互相垂直的线？ 板书设计 线与角 直线没有端点，射线有一个端点，线段有两个端点。 在同一个平面内，两条直线的相互位置是平行或相交。两条直线相交成直角这两条直线叫做垂直；在同一平面内不相交的两条直线叫平行。 教学反思： 21、平面图形 学习目标 1、能够按照一定的标准对平面图形进行分类。 2、掌握各种平面图形的特征。 3、通过观察、操作、了解三角形两边之和大于第三边。 学习重点寻找复习平面图形的角度和方法。 学习难点在观察、操作中体会平面图形的特征及应用。 学习准备多媒体，直尺，三角尺。 教学过程： 一、自主尝试: 1、我们学过哪些平面图形？ 2、我们可以从哪些角度去梳理平面图形？ 二、合作探究： 根据哪些特征可以把平面图形分成哪些类？ 学生讨论，使学生知道，从边的角度，角的角度。
小学六年级数学毕业试卷 学校班级姓名 一、填空。（每空1分，共15分。） 1、5时24分＝（ 5.4 ）时 8平方米6平方分米＝（ 806 ）平方米 2、由3个亿、8个千万、9个万、6个千和5个百组成的数写作（ 380096500 ），四舍五入到亿位约是（ 4亿）。 3、在1∶2000的地图上量得甲、乙两地距离是36厘米，甲、乙两地的实际距离是（ 720 ）米。 4、如果在1:5的前项加上2，要使它的比值不变，后项应增加（10 ） 5、a×4=5×b，(a≠b),那么b和a成（正）比例。 6、m、n是非零自然数，m÷n=1……1，那么m和n的最大公因数是（ 1 ）最小公倍数是（ mn ） 7、一个三角形三个内角的度数比是1∶1∶2，这个三角形是（等腰直角）三角形。 8、一个圆形花坛直径为8米，绕花坛有一条小路，宽3米，这条小路的面积是（103.62）平方米。 9、一台收音机原价100元，先提价10％，又降价10％，现在售价是（ 99 ）元。 10、等底等高的圆柱和圆锥体积之差是4.6立方分米，圆柱的体积是（ 6.9 ）立方分米 11、小东、小明和小军三人同在一张球桌上练习打乒乓球，他们轮流上场共打了一小时，平均每人打球（ 40 ）分钟。 12、32名同学正在10张乒乓球桌前进行单打或双打比赛，正在进行双打比赛的乒乓球桌有 （ 6 ）张。 二、选择。（每题1分，共8分。） 1、三角形的面积一定，底和高（ B ） A.成正比例； B.成反比例； C.不成比例； 2、a、b是两个不为0的自然数，a÷6＝b，a、b的最小公倍数是（ A ）
A.a ； B. b ； C.6 ； D. 6a 。 3、一种盐水，盐占盐水的10%，盐和水的重量比是（ C ） A 、1∶11 B 、1∶10 C 、1∶9 4、4、甲数的512 等于乙数的50%，则甲数是乙数的（ A ）。 A 、56 B 、65 C 、245 D 、4 25 5、把一根木头锯成7段，若每次锯的时间都相等，那么锯完每段的时间是总时间的（ B ）。 A 、15 B 、16 C 、17 D 、18 6、有5个数的平均数是20，如果把其中的一个数改成4，这时候5个数的平均数是18，改动的 数原来是（ B ）。 A.10 B.14； C.20； D.24 7、甲数是a ，它比乙数的3倍少b ，表示乙数的式子是（ B ）。 A.3a －b B.（a ＋b ）÷3 C.a ÷3－b D. 3a ＋b 8、一个圆柱的侧面展开图是一个正方形，这个圆柱的底面直径与高的比是（ A ）。 A.1：π B. 1：2π C.2：π 三、判断（5分） 1、把甲队人数的 51调入乙队后两队人数相等，原来甲队人数比乙队多32。（ √ ） 2、一瓶油5 4千克，先倒出它的51，再往瓶里加51千克。现在瓶内的油不变。 （ × ） 3、一个三角形中最小的一个内角是600，这个三角形一定是锐角三角形。 ( √ ) 4、一个数四舍五入后是8万，那么这个数最大可能是84999。 （ √ ） 5、如果3a ＝4b(a≠0，b≠0)，那么 a∶b＝ 3∶4。 （ × ） 四、计算。（34分） 1、直接写出得数（8分） 3500－700＝2800 0.4×0.2＝ 0.08 9－0.9＝ 8.1 24÷11 2＝132
常用的视频、音频、图像文件格式及其特点 常用的视频、音频、图像文件格式及其特点 一、视频文件格式 （1）、A VI格式： A VI它于1992年被Microsoft公司推出，A VI是非编中最常用的视音文件格式，可以被称为影音格式的鼻祖。它的英文全称为Audio Video Interleaved，即音频视频交错格式，所谓“音频视频交错”，就是可以将视频和音频交织在一起进行同步播放。这种视频格式的优点是图像质量好，可以跨越多平台使用，其缺点是体积过于庞大，而且更糟糕的是压缩标准不统一，最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编 码编辑的A VI格式视频，而低版本Windows媒体播放器又播放不了采用最新编码编辑的A VI格式视频。在我们的非编中，不论早期的DVStorm还是现如今的EDIUS所使用的视频文件都是A VI格式，因为它兼容性好，调用方便，图像质量好。 另外还有DV-A VI格式（摄像机采集常用），DV的英文全称是Digital Video Format，是由索尼、松下、JVC等多家厂商联合提出的一种
家用数字视频格式。目前非常流行的数码摄像机就是使用这种格式记录视频数据的。它可以通过电脑的IEEE 1394端口传输视频数据到电脑，也可以将电脑中编辑好的的视频数据回录到数码摄像机中。这种视频格式的文件扩展名一般 是.avi，所以也叫DV-A VI格式。 (2)、MPEG格式： 它的英文全称为Moving Picture Expert Group，即运动图像专家组，家里常看的VCD、SVCD、DVD就是这种格式。MPEG文件格式是运动图像压缩算法的国际标准，它采用了有损压缩方法减少运动图像中的冗余信息而达到高压缩比的目的，当然这是在保证影像质量的基础上进行的。MPEG的平均压缩比为50∶1，最高可达200∶1，压缩效率之高由此可见一斑。MPEG已成功应用于电视节目存储、传输和播出领域。目前MPEG格式有三个压缩标准，分别是MPEG－1、MPEG－2、和MPEG－4。 MPEG－1：制定于1992年，它是针对1.5Mbps以下数据传输率的数字存储媒体运动图像及其伴音编码而设计的国际 标准。也就是我们通常所见到的VCD制作格式。使用PEG-1的压缩算法，可把一部120分钟长的电影压缩到1.2GB左右
realplay流媒体服务器图解安装 站长资讯网-站长的资源库，丰富的资讯内容- 操作系统- Win2003 - realplay流媒体服务器图解安装 发表于:2009-11-6 浏览:0 作者: 来源:互联网 关键字:流媒体,服务器,REALPLAY,图解 描述:Real流媒体技术的实现基础是需要3个软件的支持的。RealPlayer播放器RealProducer 编辑制作RealServer服务器下面我们分别来介绍这三个软件。RealPlayer，这是大家众所周知的软件，从早期的R Real流媒体技术的实现基础是需要3个软件的支持的。 RealPlayer 播放器 RealProducer 编辑制作 RealServer 服务器下面我们分别来介绍这三个软件。 RealPlayer，这是大家众所周知的软件，从早期的RealPlayer发展到RealPlayer8.0，RealPlayer9.0，现在已经升级到RealOne和RealOnePlayerGold版本。Real所特有的格式为 *.rm,*.ra,*.ram。所占用的空间极小，并且有较好的影音质量，被广泛地传播在互联网上。 RealProducer，是一款编辑制作Real特有文件的软件，我们下载到的*.rm,*.ra,*.ram，文件都是从原始的影音文件，通过软件转化过来的，RealProducer无疑是一款最好的转化软件。它还有一个最大特点，而且也是我们做Real服务器必须的，就是它可以将影音文件转化成多流的影音文件，这种文件是可以根据浏览者的网速而传送不同质量的影音文件，详细的内容我们将在以后具体的转化介绍。 RealServer也是整个流媒体架设平台的核心软件，通过RealServer的建立，可以使浏览者访问服务器上的影音文件，由此实现网上在线视听。 下面就通过这三个软件来实现Real流媒体技术。 先我们先来安装这三个软件
2012年北师大版六年级数学下册期末试卷（100分） 班级 ________ 姓名 ________ 考号 ________ 成绩 _______ 一、填空（每空1分，共25分） 1.3 8 = （）% = 12 ÷（）= 9：（）= () 315 8 + + 2.二亿七千零九写作（），省略亿位后面的尾数约是（）。 3.1时45分=（）时=（）分；3050升=（）立方米。 4.3个 1 10 与（）个0.01的和是1。 5.妈妈买一件上衣花200元，比裤子贵3 5 ，裤子花了（）元。 6.a和b都是自然数，a÷b=6，a和b的最大公约数是（）。 7.4个苹果平均分给8个人，每人分得苹果总数的（），2人分到（）个。 8.A C B =（B不为0），当A一定时，B和C成（）比例。 9.小明带X元钱，买每千克b元的桃子，买了3千克，还剩（）元；如果X=30, b=4时，小明剩下（）元。 10.爸爸给汽车加了20升93#汽油，花了92元。总价与数量的比是（）：（），比值（），这个比值表示的是（）。 11.小明用圆规画一个圆，圆规两脚张开的大小是1厘米，画出圆的周长是（），面积是（）。 12.在比例尺是20：1的图纸上量得一个零件的直径是4厘米，这个零件直径的实际长度是（）毫米。 13.一个直角三角形的两条直角边长分别是3厘米和4厘米，斜边长5厘米，如果以4厘米长的直角边为轴把三角形旋转一周，得到一个圆锥体，这个圆锥体的高是（）厘米，底面半径是（）厘米，体积是（）立方厘米 二、判断（对的打“√”，错的打“×”并改正）（每小题1分，共5分） （）1.圆和半圆都有无数条对称轴。 （）2.如果3X=1 8 Y，（X、Y均不为0），那么X和Y成反比例关系。 （）3.分母是8的所有真分数的和是2。 （）4.淘气做12道题，对了12道，他的正确率是100%。。（）
最新北师大版小学六年级上册数学书中的应用题 1 .汽车车轮的半径为0.3m，它滚动1圈前进多少米？1000圈呢？ 2.笑笑绕着花坛边缘走了一周，走了62.8m这个花坛的直径是多少米？ 3.一个一面靠墙，另一面用篱笆围城的半圆形养鸡场，这个半圆的直径为6m，篱笆多长？ 4.在一个边长是10m的正方形内放置一个最大的圆。这个圆的周长是多少？ 5.一个边长为2cm的正方形和一个直径为2cm的圆，两只蚂蚁分别沿着正方形和圆走一圈，谁走的长？为什么？ 6.一个圆形杯垫的半径是4cm，这个杯垫的面积是多少平方厘米？ 7.有一个圆形蓄水池。它的周长是31.4m，它的占地面积是多少？ 8.北京天坛公园的回音壁是闻名世界的声学奇迹，它是一道圆形围墙。圆的直径约为61.5m，周长与面积分别是多少？（结果保留一位小数） 9.一个运动场两边是半圆，中间是长方形，长方形的长是50m，宽式 20m，这个运动场的占地面积是多少？ 10.某钟表的分针长10cm. (1)从1时到2时，分针针尖走过了多少厘米？（2）从1时到2时，分针扫过的面积是多少平方厘米？ 11.一个水缸的直径是1m。要为这个水缸做一个盖子，这个盖子的面积至少是多少平方米 12.长12.25m的绳子，正好绕树干10圈。树干横截面的直径是多少呢？ 13.一个圆形和一个长方形的面积相等。圆的直径和长方形的长都是16cm。长 方形的宽是多少厘米？
14.淘气用两根长度都是62.8cm的铁丝分别围城正方形和圆。它们围城的面积一样大吗？ 15.某汽车车轮的直径为0.5cm，汽车行驶到1km时，车轮大约转了多少圈？ 16.一只羊栓到木桩上，绳子长6m，羊能吃到草的面积有多大？ 17.我国约有660个城市。其中约2／3的城市供水不足。在这些供水不足的城市中，又有的城市严重缺水。全国严重缺水的城市大约有多少个？ 18.一本故事书有820页，第一周看了全书的，第二周看的是第一周的，第二周看了多少页？ 19.有两只船，大船一次可以运载5吨货物，小船一次运载的货物是大船的大船6次运完的货物，如果改用小船运，几次运完？ 20.有3瓶饮料。每瓶如果每杯装。能装9杯吗？ 21.十一黄金周，游乐场第一天的门票收入为960元，第二天比第一天增加了第二天的门票收入是多少？画出图形，在运算。 22.水结成冰后，体积大约增加现有20L的水，能竭诚多少立方分米的冰？ 23.一本故事书有140页，奇思已经看了这本书的，还剩多少没有看？ 24.笑笑的体重是40KG，淘气的体重比笑笑重，淘气的体重是多少？ 25.淘气的体重是45KG，笑笑比淘气轻笑笑的体重是多少？ 26.公园的园丁新种植了480盆花，其中杜鹃花占，月季花占，新种植的这两种花共有多少盆？ 27.越野赛跑全程12KM。其中环山路占，海滨路占，其余的是公路。（1）环山路段比海滨路长多少千米？ （2）如果明年把赛跑全程延长，将是多少米？
一圆 1 圆的认识（一） 1．对称轴，无数2．圆心，位置，半径，大小，直径，半径3．C4．5 5．46．都相等7．C8．无数，以A为圆心2.5cm为半径的圆上 9．（1）5，10；（2）a，2a10．411．宽是4cm12．略 聚沙成塔 2 圆的认识（二） 1．（1）半径，r，无数，相等；（2）直径，d，无数，相等2．2，1 2 3．（1）14；（2）8；（3） 2a4．10 5．2.5 6．（1）对；（2）错；（3）对；（4）错；7．（1）4.4cm，2.2cm；（2）1.5cm，1cm；（3）4.5cm，2.25 cm；（4）4cm，4cm，2cm8．略9．8，410．轴对称，对称轴11．2，4，1，1，1，无数，312．长24cm，宽9cm 3 圆的周长 1．（1）7π；（2）4π；（3）500，10002．（10π+20）米3．6厘米4．周长 5．10，20π6．3，6π7．0.71×3.14=2.2294（米）≈2.2（米）8．（8+4π）cm 9．C1=4×4+4π=16+4π（cm）；C2=4×4+4π×4×1 4 =16+4π（cm）；C3=4×4+2π×4=16+8π（cm） ∴第三个图的阴影部分周长最长10．（15.7×4）÷3.14=20cm 11．设直径为x米，则4×3.14x+1.72=8，解得x=0.5，答：略 12．6π+2×6+4=6π+16（cm）13．1 4 ×2π×5= 5 2 π（cm） 聚沙成塔：红、黑蚂蚁一起到达终点． 4 圆的面积 1．长方形，半径或周长一半，周长一半或半径，πr22．半径4米，周长8π米，面积16π平方米3．半径1.5，面积7.065 4． 5．（1 7．半径为2.5分米；面积为6.25π平方分米；剩余面积为（60-6.25π）平方分米 8．增加13π平方米9．B10．A11．6个圆的阴影部分面积相等，都为（4-π）cm212．设半 圆半径为r，则2r+πr=15.42，解得r=3（分米），所以面积：3.14×9×1 2 =3.14×4.5=14.13（平 方米）13．（1）（2500+625π）平方米；（2）230×（2500+625π）=575000+143750π（元）14．面积：4π2平方分米15．半径为300米，面积：282600平方米
常用网页播放器代码 我们在网页上看到的播放器无外乎WMP/RealOne/Macromedia Flash Player,其他的无非是面板不同，或者添加了其他控件，对于计算机上安装的一些播放器也都是编码和解码器的整合，其最核心的编码和解码技术是相同的。例如：网络上最流行的windows media流(asf,wma,wmv格式...)，Real流(rm,rmvb...)，还有MPEG系列编码格式(MP4/MP3格式...) Windows Media Video 是微软推出的一种流媒体格式，它是在“同门”的ASF（Advanced Stream Format）格式升级延伸来得.在同等视频质量下，WMV格式的体积非常小，因此很适合在网上播放和传输。Windows Media Player9兼容所有格式的WMV,官方编码器是Windows Media Encoder ，但是如果你想转制高质量的wmv文件，那您一定要有超大的内存来处理数据... 无意中发现CASTPOST的播放器可以自己定义大小，对于WMV格式的在线播放可以说已经足够快了,然后就费了好大劲把一些精彩的短片和一些经典的MTV转化WMV格式放了上来,尽管现在不能下载了，但是只要不是连接人数过多，播放起来还是很流畅的^_^ WMP加入了ActiveX解码器控件，不仅可以放曲子，还能放Flash和其它视频文件
第一单元圆 圆概念总结 1．圆的定义：平面上的一种曲线图形。 2．将一张圆形纸片对折两次，折痕相交于圆中心的一点，这一点叫做圆心。圆心一般用字母O表示。它到圆上任意一点的距离都相等． 3．半径：连接圆心到圆上任意一点的线段叫做半径。半径一般用字母r表示。把圆规两脚分开，两脚之间的距离就是圆的半径。 4．圆心确定圆的位置，半径确定圆的大小。 5．直径：通过圆心并且两端都在圆上的线段叫做直径。直径一般用字母d表示。6．在同一个圆内，所有的半径都相等，所有的直径都相等。 7．在同一个圆内，有无数条半径，有无数条直径。 8．在同一个圆内，直径的长度是半径的2倍，半径的长度是直径的一半。 用字母表示为：d＝２r r ＝1 d 2 用文字表示为：半径=直径÷2 直径=半径×2 9．圆的周长：围成圆的曲线的长度叫做圆的周长。 10．圆的周长总是直径的3倍多一些，这个比值是一个固定的数。我们把圆的周长和直径的比值叫做圆周率，用字母π表示。圆周率是一个无限不循环小数。在计算时，取π≈3.14。世界上第一个把圆周率算出来的人是我国的数学家祖冲之。 11．圆的周长公式：C=πd 或C=2πr 圆周长=π×直径圆周长=π×半径×2 12、圆的面积：圆所占面积的大小叫圆的面积。 13．把一个圆割成一个近似的长方形，割拼成的长方形的长相当于圆周长的一半，用字母（πr）表示，宽相当于圆的半径，用字母（r）表示，因为长方形的面积=长×宽，所以圆的面积= πr×r。圆的面积公式：Ｓ＝πｒ2。 14．圆的面积公式：Ｓ＝πｒ2或者S=π（d÷2）2或者S=π（C÷π÷2）215．在一个正方形里画一个最大的圆，圆的直径等于正方形的边长。 16．在一个长方形里画一个最大的圆，圆的直径等于长方形的宽。 17．一个环形，外圆的半径是R，内圆的半径是r，它的面积是S=πR2－πｒ2或S=π（R2－ｒ2）。 （其中R＝r＋环的宽度．）
常见视频的格式转换方法 一、常见的视频格式 1、ASF ASF 是Advanced Streaming format 的缩写，由字面（高级流格式）意思就应该看出这个格式的用处了吧。说穿了ASF 就是MICROSOFT 为了和现在的Real player 竞争而发展出来的一种可以直接在网上观看视频节目的文件压缩格式。由于它使用了MPEG4 的压缩算法，所以压缩率和图像的质量都很不错。因为ASF 是以一个可以在网上即时观赏的视频“流”格式存在的，所以它的图象质量比VCD 差一点点并不出奇，但比同是视频“流”格式的RAM 格式要好。不过如果你不考虑在网上传播，选最好的质量来压缩文件的话，其生成的视频文件比VCD （MPEG1）好是一点也不奇怪的，但这样的话，就失去了ASF 本来的发展初衷，还不如干脆用n A VI 或者DIVX 。但微软的“子弟”就是有它特有的优势，最明显的是各类软件对它的支持方面就无人能敌。 2、n A VI n A VI 是newA VI 的缩写，是一个名为ShadowRealm 的地下组织发展起来的一种新视频格式。它是由Microsoft ASF 压缩算法的修改而来的（并不是想象中的A VI），视频格式追求的无非是压缩率和图象质量，所以nA VI 为了追求这个目标，改善了原始的ASF 格式的一些不足，让nA VI 可以拥有更高的帧率（rate）。当然，这是以牺牲ASF 的视频流特性作为代价的。概括来说，nA VI 就是一种去掉视频流特性的改良型ASF 格式，再简单点说，就是非网络版本的ASF。 3、A VI A VI 是Audio Video Interleave 的缩写，这个看来也不用多解释了，这个微软由WIN3.1 时代就发表的旧视频格式已经为我们服务了好几个年头了。如果这个都不认识，你就别往下看了。这个东西的好处嘛，无非是兼容好、调用方便、图象质量好，但缺点也是人所共知的：尺寸大，就是因为这点，我们现在才可以看到由MPEG1 的诞生到现在MPEG4 的出台。 4、MPEG MPEG 是Motion Picture Experts Group 的缩写，它包括了MPEG-1, MPEG-2 和MPEG-4 （注意：没有MPEG-3，大家熟悉的MP3 只是MPEG Layeur 3）。 MPEG-1相信是大家接触得最多的了，因为它被广泛的应用在VCD 的制作和一些视频片段下载的网络应用上面，可以说99% 的VCD 都是用MPEG1 格式压缩的，（注意：VCD2.0 并不是说明VCD 是用MPEG-2 压缩的）使用MPEG-1 的压缩算法，可以把一部120 分钟长的电影（未视频文件）压缩到1.2 GB 左右大小。 MPEG-2 则是应用在DVD 的制作（压缩）方面，同时在一些HDTV（高清晰电视广播）和一些高要求视频编辑、处理上面也有相当的应用面。使用MPEG-2 的压缩算法压缩一部120 分钟长的电影（未视频文件）可以到压缩到4—8 GB 的大小（当然，其图象质量等性能方面的指标MPEG-1 是没法比的）。 MPEG-4 是一种新的压缩算法，使用这种算法的ASF 格式可以把一部120 分钟长的电影（未视频文件）压缩到300M 左右的视频流，可供在网上观看。其它的DIVX 格式也可以压缩到600M 左右，但其图象质量比ASF 要好很