The present invention is directed to the transmission of data between computers, and, more particularly, to a method of controlling the supply of streaming media sent from a server to a client over the Internet.
With the continuing expansion of the Internet the transfer of data between different computers over the Internet is becoming ever more widespread. Computers today exchange data over the Internet using a variety of different types of connections. Connections such as T-1 and T-3 lines, cable modems, and DSL have high data transfer rates, typically on the order of 100-1000 Kbits/sec., and are referred to as high bandwidth or broadband connections. Connections such as telephony modems have lower data transfer rates, typically on the order of 15-56 Kbits/sec., and are characterized as low bandwidth connections. Bandwidth is important because it affects to the amount of data which can be passed between computers over the Internet. The term xe2x80x9cdataxe2x80x9d is used broadly and, by way of example, refers to any type of information that can be transmitted over the Internet, such as numbers, text, images, sounds and computer programs.
FIG. 1 is a schematic view showing a number of client computers C0, C1, C2 and C3 and server computers S0, S1 and S2 all connected to the Internet. Client C1 and server S1, it should be noted, are joined to the Internet by wireless connections.
Data sent over the Internet may vary in size greatly, depending upon the nature of the data which is sent. One particularly bulky type of data is streaming media data. The term xe2x80x9cstreaming mediaxe2x80x9d refers to audio, video or audio-video data with or without text that has a chronological component and which is therefore played over time. Streaming media data is typically transferred from a content provider to a user. When this transfer takes place over a network, the content provider uses a server computer having the appropriate server software to respond to requests for data, and the user employs a computer having the appropriate client software to send requests for data and receive and process responses to those requests.
Users typically exchange data over the Internet using Internet browser software. Browsers are capable of displaying a wide variety of different file formats that are commonly sent over the Internet, such as TIFF, JPG, HTML, TXT, WAV and so forth. Examples of browsers include NETSCAPE NAVIGATOR(copyright) by Netscape Corporation and (copyright) by Microsoft Corporation. Since the operation of browser software is generally known, such operation will not be described in detail.
In some instances, a browser may be unable to display the data sent by a content provider""s server because that data is in an unsupported file format. In that case the browser may require a supplemental xe2x80x9cplug-inxe2x80x9d program to display the data. Such plug-in programs can be written as Java applets or ActiveX controls. A wide range of different types of plug-in programs are known.
One type of data that generally cannot be displayed by a browser is streaming media data. When receiving streaming media data a browser will call up a particular type of plug-in program known as a media player to process and display such data. The media player cooperates with the browser and displays the streaming media data as that data accumulates in a buffer in the user""s client computer. Typically, the browser program calls up the media player plug-in, which in turn calls the objects that drive the media player, as downloading of the streaming media data from the content provider""s server computer to the user""s client computer begins.
Examples of media player programs include QUICKTIME(copyright) by APPLE COMPUTER, INC.(copyright), REALPLAYER(copyright) by REALNET WORKS(copyright), and Windows Media Player by Microsoft Corporation.
Streaming media can be sent over the Internet using UDP (User Datagram Protocol). According to UDP, packets of compressed audiovisual data are sent from the content provider to the user over the Internet without verification that all packets have been received. By avoiding such verification data transfer is speeded. The data packets are stored at the user""s computer in a buffer until the buffer fills, at which point the media player program begins playing the media. Data packets continue to be delivered to the buffer as the media plays, hence the name xe2x80x9cstreamingxe2x80x9d. In this way, the media player begins playback before all of the streaming media data is received, and can continue playback until the buffer runs out of data.
Preferably, the content provider""s server sends the user streaming media data in a form which is optimal for the bandwidth of the user""s Internet connection. If the bandwidth of the user""s connection is high, the server can send detailed streaming media data, resulting in a large, lifelike and smooth display. If the bandwidth is low, less data should be sent, resulting in a smaller and lower-quality image.
Included with the streaming media data sent by the content provider""s server to the user may be information instructing the user""s computer how to configure the media player to display the streaming media data. That is, high resolution streaming media data may be accompanied by an instruction to the user""s computer to display the streaming media in a large media player window. Low resolution streaming media data may be accompanied by an instruction to the user""s computer to display the streaming media in a small media player window.
For good playback quality the streaming media data should be supplied to the media player at least as quickly as the media player can display that data. If the media player display the streaming media data faster than such data is received, the data buffer will empty, after which jerking, skipping and poor quality playback will occur. This is a particular problem for users having low bandwidth Internet connections; the low bandwidth connections mean users either will receive low-quality displays, or, since their computers may not receive fresh streaming media data fast enough for proper display, may experience jerking and skipping of the program being played. It is therefore very important that the content provider send to the user streaming media data of the appropriate type and at the correct rate. This can be done in a number of ways, for example, by reducing the size of the displayed image, decreasing the image""s frame rate (frame rate refers to the number of times per second that the displayed image changes), and decreasing the quality of the accompanying audio playback.
Thus, when sending streaming media data from a content provider""s server to a user""s client, it is preferable that the server know the bandwidth of the user""s Internet connection. This way the content provider can send data to the user at the appropriate rate, and in the appropriate format (i.e., resolutions and size).
Although this problem can to some extent be solved by having the content provider""s server send streaming media data with the assumption all users have low bandwidth connections, this would disadvantageously reduce the quality of the playback for those users having high bandwidth connections.
Another solution to this problem is to control the quality of streaming media playback according to the known bandwidth of the user""s Internet connection; users having high bandwidth Internet connections would receive higher resolution data than users having low bandwidth Internet connections. To do this, websites distributing streaming media content may wait to send streaming media data until the user has indicated the bandwidth of their Internet connection. This way, streaming media data appropriate for the bandwidth of the user""s Internet connection can be sent. One way to accomplish this is to place on the appropriate web page at the content provider""s website different hyperlinks corresponding to different possible Internet connection bandwidths. Each hyperlink, when activated (xe2x80x9cclickedxe2x80x9d) sends information to the content provider about the user""s bandwidth, and may be accompanied by a request to transfer to the user""s computer specific resolution streaming media data. For example, users might be offered a choice of two different high bandwidth connections speeds, i.e., 300 Kbps and 100 Kbps, and two different low bandwidth connection speeds, i.e., 56 Kbps and 28.8 Kbps. Each hyperlink would, when activated, inform the content provider of the user""s bandwidth so that the content provider""s server can send to the user streaming media data with a resolution appropriate for the indicated Internet connection""s bandwidth. Alternatively, the user might first indicate their bandwidth and then be given a choice of media to download from the content provider.
Optionally, the content provider""s server could set a cookie on the user""s computer defining the bandwidth of the user""s Internet connection. By setting this cookie the user need not again indicate the bandwidth of their Internet connection when they return to the site.
Nevertheless, such manual selection of streaming media by the user according to the bandwidth of the user""s connection has several disadvantages. First, this requires the user to take action, which slows the user""s browsing experience. Second, the user may select the wrong link; should the user inadvertently choose a link for a lower bandwidth connection than is appropriate, the user will see a lower quality image that necessary. If the user selects a link for a higher bandwidth connection than is optimal, the user""s computer may not be able to receive streaming media data at that rate. In such a case, the lack of data could cause playback to skip and jerk. In addition, if the user refuses to allow a cookie reflecting the bandwidth of the user""s Internet connection to be set, or the user has deleted such a cookie, the user, when returning to the website, will again have to choose the appropriate download link when they return to the site and attempt to download streaming media content. Each of these actions can contribute to user frustration, which may adversely affect site viewership.
The present invention is directed to a system for controlling the transmission of data from a content provider to a user over the Internet based upon the bandwidth of the user""s connection to the Internet.
More particularly, this invention measures the bandwidth of a user""s Internet connection each time a user requests data such as streaming media data from a content provider and, having measured the bandwidth of the user""s connection to the Internet, sends the user the data in a form optimized for the measured bandwidth.
In a further embodiment, this invention determines the bandwidth of the user""s Internet connection when the user first visits a content provider""s site. The content provider then stores information regarding the determined bandwidth and that stored information is used so that the user is sent data optimized for the measured bandwidth. The stored information can be used only for the immediate session only, for a predetermined period of time, or even in separate sessions. By using the stored information the content provider avoids the need to again measure the bandwidth of the user""s Internet connection.
The present invention involves a method for measuring the bandwidth of a signal path between a data source and a data recipient. This can be done by sending a block of test data from the data source along the signal path to the data recipient, using that test data to measure the time needed to transfer that data, and so obtain a measured bandwidth of the signal path. Streaming media data or other information is then transferred from the data source along the signal path to the data recipient based upon the measured bandwidth. If desired, the bandwidth can be measured each time the data recipient visits the website or the bandwidth can be stored for future use. The signal path can include the Internet and the information may be streaming media data.
A further and optional aspect of this invention involves determining whether the measured time falls within a range and only if the measured time falls within that range is the measured time used to determine a measured bandwidth of the signal path. If the measured time is below the range, a different block of test data is sent along the signal path to obtain a further measured bandwidth and transfer of information takes place in accordance with the further measured bandwidth. Should the measured time exceed the range, use of the measured time to determine the bandwidth of the signal path is delayed.
Additionally, in an alternate embodiment, this invention includes detecting whether the signal path""s bandwidth was previously determined. If that bandwidth already was determined and is available then the known bandwidth value is used, instead of measuring the bandwidth anew.