System for controlling data output to a network

[0002] 1. Field of the Invention

[0003] The present invention is directed to a system for controlling the flow of data to a network based on a rate at which data is read from the network. The invention has particular utility in connection with transmitting video data over the Internet, since it reduces data overflow, data underflow, and network congestion, thereby enhancing video quality.

[0004] 2. Description of the Related Art

[0005] Existing network systems currently have the ability to transmit real-time video, comprised of audio-visual data, between different nodes. The Internet in particular has, in recent-years, experienced a marked increase in the amount of video being passed therethrough. As anyone who has experienced networked video (in particular, Internet video) is aware, however, it leaves much to be desired. For example, motion in such video often appears stilted, rather than fluid. Likewise, image motion and audio data may not coincide, thereby further degrading the quality of the video.

[0006] There are a number of reasons for the foregoing problems with network video, one of which relates to flow control of data moving through the network. Taking the Internet as an example, the Internet uses user datagram protocol (“UDP”) in processing data from “streaming” applications, i.e., multimedia applications which output “streams” of video data to the Internet. UDP, however, has no inherent flow control, meaning that it outputs video data without regard to the amount of data currently on the network. In cases where the network is already at capacity, this can result in a loss of video data, thereby decreasing the quality of the video, as described above. On the other hand, where there is excess capacity on the network, this can result in gaps in the video data, and thus in the resulting video, which likewise decreases the video's quality.

[0007] Additional problems also arise from the lack of flow control inherent, in particular, in UDP-orientated multimedia applications. More specifically, because these applications output video data without regard to the current capacity of the network, they can be a threat to existing applications, like ftp, telnet, etc., that run atop more socially-minded protocols such as transport control protocol (“TCP”). In fact, a proliferation of poorly-designed UDP multimedia applications can congest the Internet resulting, in the most extreme case, in a congestion collapse thereof.

[0008] Conventional developers have addressed the foregoing problems in the art by synchronizing the operation of a transmitter which outputs data to a network with the operation of a receiver which reads data from the network. For example, the Network Voice Terminal (“NeVoT”) application, developed by the University of Massachusetts for audio-conferencing over a network, uses a single audio sampling clock to control transfer of audio data from an input device (e.g., a microphone) to the network, and from the network to an output device (e.g., a speaker). That is, each time the input device delivers a full block of audio to the application, one equal duration block of audio is copied from a playout buffer on the network to the output device.

[0009] While the foregoing solution reduces buffer overflow and underflow by coupling input and output timing, it has several drawbacks resulting from the fact that it does not take into account the characteristics of the intermediate network. For example, in the conventional flow control method described above, data is sent to the network at as high a speed as the network interface can handle, regardless of the bandwidth of the network. If the network has a bandwidth that cannot handle high bitrates, this will lead to congestion on the network, which can cause data loss and degrade network performance.

[0010] Accordingly, there exists a need for a system which controls the flow of data to a network, such as the Internet, so as to reduce both network congestions and the deleterious effects resulting from buffer overflow and underflow.

[0011] The present invention addresses the foregoing need by determining an amount of data that has been read from a network (e.g., the Internet) in a predetermined time period, and then outputting substantially the same amount of data to the network in the same predetermined time period. By controlling the rate at which data is output to the network in this manner, the present invention is able to reduce network congestion, without introducing substantial buffer overflows and/or underflows into the system.

[0012] Thus, according to one aspect, the present invention is a system (i.e., a method, an apparatus, and computer-executable process steps) which controls data output to a network. The system determines a maximum amount of data that could be output to the network based on an amount of data that can be read from the network during a predetermined time period, and then obtains a difference between an amount of data which has actually been output to the network and the maximum amount. Thereafter, the system outputs, to the network and within the predetermined time period, an amount of data packets that is based on the difference.

[0013] In preferred embodiments, these data packets include intra (“I”) frames of video, together with predictive (“P”) frames and/or bi-directional (“B”) frames of video. In these embodiments, the intra frames are output to the network, while at least some of the predictive frames and/or the bi-directional frames are not. Whether the predictive and/or bi-directional frames are, or are not, output varies depending upon the bandwidth of the network. By virtue of these features of the invention, it is possible to preserve the most important frames (i.e., the intra frames) when the bandwidth of the network is not sufficient to accommodate all frames. This most often, although not always, occurs in the case of variable-bandwidth networks.

[0014] In other preferred embodiments of the invention, for a last data packet to be output to the network in the predetermined time period, the system determines a first number of bits by which an amount of data will exceed the difference in the event that the data packet is output to the network, determines a second number of bits by which an amount of data will fall short of the difference in the event that the data packet is not output to the network, and outputs the data packet in a case that the first number is less than the second number, but not in a case that the first number is greater than the second number. By virtue of these features, the invention is able to output an amount of data to the network which most closely corresponds to the network's capacity. The invention is therefore able to maintain as high a data throughput as possible under the circumstances, without substantial buffer overflow and/or underflow.

[0015] In still other preferred embodiments, the invention determines the maximum amount of data which could be output to the network based on a maximum amount of data that can be handled by a network segment having the least amount of available bandwidth. That is, in this case, the “bottleneck” (i.e., the portion of the network having the least amount of available bandwidth) will dictate the maximum rate at which data can be output to, and read from, the network. To accommodate this, the present invention allows the bandwidth of the bottleneck to control the flow of data to and from the network. This reduces the chances of network congestion and buffer overflow and underflow resulting from the bottleneck.

[0016] According to another aspect, the present invention is a network system in which flows of video data are controlled so as to reduce data congestion on the network. The network system includes a transmitter which codes the video data and which outputs coded video data to the network. Also included in the system is a receiver which reads the coded video data from the network at a predetermined rate (which is dictated, e.g., by the bandwidth of the network's bottleneck), which decodes the coded video data, and which forms images based on the decoded video data. According to the invention, the transmitter outputs the coded video data to the network at substantially a same rate at which the receiver reads the coded video data from the network. By outputting the coded video data to the network at substantially the same rate at which the receiver reads the coded video data from the network, the invention is able to reduce network congestion and, in addition, to reduce occurrences of substantial buffer overflow and underflow.

[0017] This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiment thereof in connection with the attached drawings.

[0018] FIG. 1 shows a network system on which the present invention may be implemented.

[0019] FIG. 2 shows a close-up view of computing equipment for video data transmitting and receiving nodes on the network system of FIG. 1.

[0020] FIG. 3 shows the architecture of a PC included in the computing equipment of FIG. 2.

[0021] FIG. 4 shows the location of the flow controller of the present invention in a data stream between a multimedia application and the network.

[0022] FIG. 5 shows process steps for implementing the invention.

[0023] FIG. 6 shows various segments of the network shown in FIG. 1, each having a different bandwidth.

[0024] FIG. 7 shows the effective bandwidth of the network for the purposes of the invention, which bandwidth is the least amount of available bandwidth for the segments depicted in FIG. 6.

[0025] FIG. 1 shows an example of a network system 1 on which the present invention may be implemented. As shown in FIG. 1, network system 1 includes plural nodes, such as 2 and 4, and network medium 5. Network medium 5 may be, e.g., an Ethernet cable, wireless link, or a combination thereof, over which data packets comprised of video data (i.e., audio-visual data) and other information are transmitted between various nodes. In this regard, network 1 can comprise any type of network, such as a local area network (“LAN”), a wide area network (“WAN”), a variable-bandwidth network, an ATM network, the Internet, etc.

[0026] For the purposes of the present invention, node 2 comprises a transmitter which receives video data from an input device, such as a digital video camera or the like (not shown), which codes the video data, and which outputs the coded video data to the network. Alternatively, node 2 could include pre-stored coded data, which is output to the network. For the purposes of the present invention, node 4 comprises a receiver which receives the coded video data. In operation, node 4 reads the coded video data from the network at a predetermined rate, decodes the coded video data, and forms images based on the decoded video data on an output device, such as its display screen or the like. As described in more detail below, flow control is effected by node 2 (the transmitter) by outputting the coded video data at substantially a same rate at which node 4 (the receiver) reads the coded video data from the network.

[0027] Nodes 2 and 4 can comprise any type of digital data transmitting and receiving devices. These include, but are not limited to, video conferencing equipment and a digital television system (e.g., a transmitter and a digital television and/or a settop box) such as that described in U.S. patent application Ser. No. 09/062,939, entitled “Digital Television System Which Selects Images For Display In A Video Sequence”, filed on Apr. 20, 1998, the contents of which are hereby incorporated by reference into the subject application as if set forth herein in full. However, for the sake of simplicity, the invention will be described in the context of two networked computers, each of which has the capability to transmit video data to, and read video data from, the network in the manner described herein.

[0028] FIG. 2 shows a representative embodiment of computing equipment 6 for the networked computers comprising nodes 2 and 4. As shown in FIG. 2, personal computer (“PC”) 7 includes network connection 9 for interfacing to network 5 and fax/modem connection 10 for interfacing with the network or other devices such as a digital video camera (not shown) which inputs video data to PC 7. PC 7 also includes display screen 11 for displaying information (including video) to a user, keyboard 12 for inputting text and user commands, mouse 14 for positioning a cursor on display screen 11 and for inputting user commands, disk drive 15 for reading from and writing to floppy disks installed therein, and digital video disk (“DVD”) drive 16 for inputting and accessing video stored on DVD. PC 7 may also have one or more peripheral devices connected thereto, such as printer 17 or the like.

[0029] FIG. 3 shows the internal structure of PC 7. As shown in FIG. 3, PC 7 includes memory 19, which comprises a computer-readable medium such as a computer hard disk and/or RAID (“redundant array of inexpensive disks”). Memory 19 stores data 20, applications 21, print driver 22, and operating system 24. In preferred embodiments of the invention, operating system 24 is a windowing operating system, such as Microsoft® Windows98; although the invention may be used with other operating systems as well. Among the applications stored in memory 19 are multimedia application 25, video coder 26, video decoder 27, and flow controller 29.

[0030] In brief, multimedia application 25 can comprise any of a number of well-known multimedia applications for processing, viewing, and editing video. As shown in FIG. 4, video coder 26 comprises a video encoding application which encodes video data output from multimedia application 25. Any of a number of well-known coding techniques may be used, including, but not limited to, DVB, MPEG-1, MPEG-2 and MPEG-4. Video decoder 27 comprises a video decoding application which decodes video data coded, e.g., according to one of these techniques. Flow controller 29 implements the present invention by controlling the output of coded video data to network 5, as described in detail below. In this regard, although the preferred embodiment of the invention is used in connection with controlling the flow of coded video data, the invention can be used to control the flow of uncoded video (or non-video) data as well.

[0031] Returning to FIG. 3, PC 7 also includes display interface 30, keyboard interface 31, mouse interface 32, disk drive interface 34, DVD drive interface 35, computer bus 36, RAM 37, processor 39, and printer interface 40. Processor 39 preferably comprises a microprocessor or the like for executing applications, such those noted above, out of RAM 37. Such applications, including multimedia application 25, video coder 26, video decoder 27, and flow controller 29, may be stored in memory 19 (as noted above) or, alternatively, on a floppy disk in disk drive 15 or a DVD in DVD drive 16. Processor 39 accesses applications (or other data) stored on a floppy disk via disk drive interface 34 and accesses applications (or other data) stored on a DVD via DVD drive interface 35.

[0032] Application execution and other tasks of PC 7 may be initiated using keyboard 12 or mouse 14, commands from which are transmitted to processor 39 via keyboard interface 31 and mouse interface 32, respectively. Output results from applications running on PC 7 may be processed by display interface 30 and then displayed to a user on display 11 or, alternatively, output to network 5 via network connection 9. For example, input video data which has been processed by multimedia application 25 and then coded by video coder 26 is typically output via network connection 9 by flow controller 29, as shown in FIG. 4. On the other hand, coded video data which has been received from the network is decoded by video decoder 27 and then displayed on display 11 using the multimedia application. To this end, display interface 30 preferably comprises a display processor for forming video images based on decoded video data provided by processor 39 over computer bus 36, and for outputting those images to display 11. Output results from other applications, such as word processing programs, running on PC 7 may be provided to printer 17 via printer interface 40 (or alternatively, to a printer on network 5—not shown). Processor 39 executes print driver 22 so as to perform appropriate formatting of such print jobs prior to their transmission to the printer.

[0033] Turning to flow controller 29, this application is executed by transmitter 2 in order to transmit coded video (or other) data to the network. In brief, flow controller 29 comprises computer-executable code (i.e., process steps) to control data output to the network by determining a maximum amount of data that could be output to the network based on an amount of data that can be read from the network during a predetermined time period, and then obtaining a difference between an amount of data which has actually been output to the network and the maximum amount. Thereafter, flow controller 29 outputs, to the network and within the predetermined time period, an amount of data packets that is based on the difference. For a last data packet to be output to the network in the predetermined time period, flow controller 29 determines a first number of bits by which an amount of data will exceed the difference in the event that the data packet is output to the network, determines a second number of bits by which an amount of data will fall short of the difference in the event that the data packet is not output to the network, and outputs the data packet in a case that the first number is less than the second number. Otherwise, the data packet is not output to the network.

[0034] In more detail, FIG. 5 shows process steps for implementing flow controller 29. To begin, step S501 determines a buffer capacity of the network (e.g., network 5). In this regard, while data packets are on the network, the network effectively acts as a buffer, the capacity of which is based on the network's bandwidth and the network delay. In this regard, the network delay comprises the time it takes for data packets to move from a client to a server in one direction on the network. The bandwidth used to calculate the buffer's capacity is the minimum available bandwidth on the network taking into consideration other network users, as well as other factors pertaining to the network, such as capacity and the like. This minimum available bandwidth is referred to herein as the network's “bottleneck” bandwidth. In this regard, the invention may be used with networks comprised of a plurality of different segments, each having a different bandwidth. The segment having the least amount of available bandwidth is thus used to determine the network's buffer capacity, whilst the remaining bandwidths are disregarded. The reason for using the least amount of available bandwidth, rather than the other bandwidths, is that the bottleneck bandwidth dictates the maximum bitrate that the network can handle without losing substantial amounts of data and/or becoming unduly congested.

[0035] Thus, as shown in FIG. 6, network 5 may include plural segments having bandwidths B₁, B₂and B₃. In this case, bandwidth B₂comprises the least amount of available bandwidth on the network, and thus the bottleneck bandwidth. Accordingly, for the purposes of the present invention, network 5 can be abstracted as shown in FIG. 7. That is, network 5 can be thought of as having a single bandwidth B₂. Once the bottleneck bandwidth has been determined, step S501 determines the buffer capacity of network 5 using the bottleneck bandwidth and the network delay for network 5. Specifically, the buffer capacity of network 5 is determined as follows

[0036] Capacity=B₂*Network Delay.  (1)

[0037] As noted above, the network delay comprises the time it takes for data packets to move from a client to a server in one direction on the network, i.e., as opposed to a round trip.

[0038] Following step S501, processing proceeds to step S502. In step S502, the invention outputs an amount of data to network 5 that substantially corresponds to the buffer capacity of the network. For example, the amount of data that is output can be within a predetermined range both above and below the network's buffer capacity. In the event that the amount of data exceeds the network's buffer capacity, the excess data may be absorbed by buffers that exist at each node of the network. In preferred embodiments of the invention, step S502 outputs packets of video data that have been coded by video coder 26 according to any of a number of known techniques, such as DVB, MPEG-1, MPEG-2, MPEG-4, etc.

[0039] As background, MPEG coding is performed on a frame of video data by dividing the frame into macroblocks of 16×16 pixels, each having a separate quantizer scale value. associated therewith. Motion estimation is then performed on the macroblocks so as to generate motion vectors for objects (i.e., moving images) in respective frames, and thereby reduce the amount of data that must be transmitted. The macroblocks are then divided into individual blocks of 8×8 pixels. These 8×8 pixel blocks are each subjected to a discrete cosine transform (hereinafter “DCT”) which generates DCT coefficients for each of the 64 pixels therein. DCT coefficients in an 8×8 pixel block are then divided by a corresponding coding parameter, namely a quantization weight. Thereafter, additional calculations are effected on the DCT coefficients in order to take into account the quantizer scale value, among other things. Variable-length coding is then performed on the DCT coefficients so as to generate coded video data for the frame. A more complete description of MPEG coding is provided in U.S. patent application Ser. No. 09/094,828, entitled “Pixel Data Storage System For Use In Half-Pel Interpolation”, filed Jun. 15, 1998, the contents of which are hereby incorporated by reference into the subject application as if set forth herein in full.

[0040] The motion vectors described above are used to reconstruct frames of video from existing frames. In this regard, MPEG codes base frames, called intra (or “I”) frames, and also codes data for predictive (or “P”) frames which comprise frames that are predicted from preceding I or P frames using the motion vectors, and bi-directional (or “B”) frames which are interpolated from preceding I or P frames and succeeding I or P frames. The I frames are key to accurate video reconstruction, since they include the most data. The present invention recognizes this by determining, in step S502, if there is sufficient bandwidth on the network to accommodate all frames of a video transmission. If there is insufficient bandwidth, the invention drops the frames that cannot be accommodated, starting with the P and B frames. Any I frames are dropped last, thus ensuring that as many I frames as possible are output to the network under the circumstances.

[0041] Next, in step S503, a time period/interval of a duration “t” is set. In this same step, the invention waits one such time period, during which the receiver reads data from the network. Once this data has been read, the invention can then output more data to the network, as described in detail below. In step S503, the time period can be retrieved automatically from memory. Alternatively, the time period can be set and/or changed manually via the transmitter's keyboard or mouse. In this regard, by decreasing the time period, it is possible to provide an increase in video granularity (i.e., resolution). That is, as described in more detail below, the invention outputs coded video data to the network so as to fill the network buffer at each time period. By decreasing the duration of the time period, the frequency at which the invention fills the buffer is increased (i.e., there are more intervals during which to fill the buffer). This results in increased video granularity.

[0042] Following step S503, step S504 determines a maximum amount of data that the transmitter could output to the network. Specifically, the maximum amount of data, “ET(i)”, that could be output to the network corresponds to the amount of data that the transmitter could have output to the network up through the “if^th” (i.e., the current) time period. This maximum amount of data ET(i) is based on an amount (e.g., a number of bits) of data that can be read from the network by the receiver during the i^thtime period. In this regard, the amount of data that can be read per time period is determined as follows

[0043] Amount Read=B₂*t,  (2)

[0044] where B₂comprises the network's bottleneck bandwidth and “t” comprises the duration of the current time interval “i”. Thus, ET(i), which corresponds to the maximum amount of data that could be output by the transmitter, is determined by

[0045] ET(i)=ET(i−1)+B₂*t,  (3)

[0046] where “ET(i−1)” corresponds to the amount of data that the transmitter could have output to the network up through the “i−1^st” time period. Thus, as is clear from equation (3), the maximum rate at which data can be output to the network (i.e., the maximum amount of data that can be output during the current time period) corresponds to the rate at which data is read from the network. This is set as such by the invention in order to avoid network congestion and/or buffer overflow and underflow.

[0047] Following step S504, processing proceeds to step S505. Step S505 determines an amount of data, “CT(i−1)”, that has actually been output to the network as of the start of time period “i”. This value is calculated by summing the number of bits in all packets output to the network up to the current time period. Once CT(i−1) is determined, step S506 obtains the difference between the maximum amount of data that could be output to the network from step S504 and the amount of data that has actually been output to the network from step S505. This difference, called “Q(i)”, comprises a quota of data that can be output to the network by the transmitter (i.e., the data source) during time period “i”. In mathematical terms, Q(i) is defined as follows

[0048] Q(i)=ET(i)−CT(i−1).  (4)

[0049] Following step S506, processing proceeds to step S507. In step S507, the transmitter outputs N (N≧1) data packets based on the difference determined in step S506. That is, by calculating the difference above between the maximum amount of data could be output to the network and the amount that has actually been output, the invention obtains the current excess capacity of the network, and thus the amount of additional data that the network can handle. This value is then passed to the transmitter, which outputs an amount of data (i.e., N data packets) that is less than or equal to the excess capacity of the network. Following this step, processing proceeds to step S508.

[0050] Step S508 determines whether the amount of data in the N packets (i.e., the size, “T(i)”, of the N packets) is equal to the excess capacity of the network (i.e., the difference obtained in step S506). If this is the case, processing proceeds to step S509, in which the timer is incremented and the amount of data actually output, CT(i), is updated as follows

[0051] CT(i)=CT(i−1)+T(i).  (5)

[0052] Processing then proceeds to step S510, which determines whether there is any remaining data to be transmitted. If there is no data remaining to be transmitted, processing ends. On the other hand, if data remains to be transmitted, processing returns to step S504 or, alternatively, to step S503 if a change in the timer interval is desired, whereafter the foregoing is repeated.

[0053] On the other hand, if step S508 determines that the amount of data in the N packets is not equal to the excess capacity of the network (i.e., if T(i) is not equal to the difference obtained in step S506), the network may be able to accommodate additional data packets. Accordingly, processing in this case proceeds to steps S511 to S514, which determine whether an additional packet should be output under the circumstances.

[0054] To begin, step S511 determines a first number of bits D₁by which the difference determined in step S506 (i.e., the network capacity) will be exceeded if another (i.e., N+1^st) data packet is output. Specifically, D₁is determined by adding the amount of data (i.e., the number of bits) in the N+1^stdata packet, namely P(N+1), to the number of bits comprising the N packets output in step S507, namely T(i), and subtracting from this sum the network capacity, namely Q(i). In mathematical terms, this is expressed as follows

[0055] D₁=T(i)+P(N+1)−Q(i).  (6)

[0056] Thereafter, step S512 determines a second number of bits D₂, which corresponds to the amount of excess network capacity if another (i.e., N+1^st) data packet is not output. In other words, D₂equals a number of bits by which an amount of data on the network will fall short of the network capacity if the N+1^stdata packet is not output. Specifically, D₂is determined by subtracting the number of bits comprising the N packets output in step S507, namely T(i), from the network capacity, Q(i). In mathematical terms, this is expressed as follows

[0057] D₂=Q(i)−T(i)*  (7)

[0058] Next, step S513 determines whether D₁is less than D₂. If D₁is less than D₂, this means that the amount by which the N+1^stdata packet will exceed the network's capacity is less than the amount by which the network will fall short of capacity if the N+1^stis not output. Thus, if outputting the N+1^stdata packet will cause the network to come closer to its capacity than not outputting the N+1^stdata packet, step S514 outputs the N+1^stdata packet. The amount of data which exceeds the capacity of the network may be stored in buffers at the network's nodes. Thereafter, step S509 increments the timer and updates the amount of data actually output, CT, as follows

[0059] CT(i)=CT(i−1)+P(N+1)+T(i).  (8)

[0060] Processing then proceeds to step S510, which determines whether there is any remaining data to be transmitted. If there is no data remaining to be transmitted, processing ends. On the other hand, if data remains to be transmitted, processing returns to step S504 or, alternatively, to step S503 if a change in the timer interval is desired. Thereafter, the foregoing is repeated for new data in the next time period.

[0061] Returning to step S513, if D₁is greater than D₂, this means that the amount by which the N+1^stdata packet will exceed the network's capacity is greater than the amount by which the network will fall short of its capacity if the N+1^stis not output. Thus, since not outputting the N+1^stdata packet will cause the network to come closer to its capacity than outputting the N+1^stdata packet, the N+1^stdata packet is not output. Thereafter, processing proceeds to step S509, in which the amount of data actually output, CT, is updated as follows

[0062] CT(i)=CT(i−1)+T(i).  (9)

[0063] It is noted that a value for P(N+1) is not included in equation (9) (as opposed to equation (8) above) because, in this case, an additional packet was not output. Processing then proceeds to step S510 which determines whether there is any remaining data to be transmitted. If there is no data remaining to be transmitted, processing ends. On the other hand, if data remains to be transmitted, processing returns to step S504 or, alternatively, to step S503 if a change in the timer interval is desired. Thereafter, the foregoing is repeated for new data in a next time period. At this point, it is noted that the invention is not limited to making its determinations based on outputting a single N+1^stdata packet. That is, the foregoing determinations can also be made based on outputting a plurality of data packets after the initial N data packets.

[0064] By virtue of steps S508 to S514, the invention is able to maintain the network at capacity (or as close thereto as is possible under the circumstances) without unduly congesting the network or causing substantial underflow or overflow of the network buffer. As a result, the invention is able to provide video having substantially the highest granularity possible given the amount of available network bandwidth. In this regard, as noted above, the invention preferably transmits MPEG-encoded video data, which includes I, P and B frames. In cases where the bandwidth of the network is unable to accommodate all data provided by video coder 26, as noted above, the present invention will “drop” some or all of the P and/or B frames when outputting the data packets in steps S502, S507 and/or S514, in order to conserve bandwidth for the I frames.

[0065] This most often (but not always) occurs in cases where the invention is used with variable-bandwidth networks since, when the invention is used with constant bandwidth networks, the video data can be coded at an appropriate bitrate for the network's bottleneck. In the case of a variable-bandwidth network (and constant-bandwidth networks, for that matter), the receiver can get an approximate measure of the network's bottleneck bandwidth by counting the number of bits per second that it receives from the transmitter. This bottleneck bandwidth measurement can then be communicated back to the transmitter, via the network (e.g., through RTCP, etc.), and used in the process shown in FIG. 5.

[0066] Finally, it is noted that although the preferred embodiment of the invention shows a software implementation of the invention, aspects thereof may be implemented in hardware as well. For example, the video coder, video decoder, and flow controller can all comprise discrete hardware elements. In the case of the flow controller, this means that the flow controller can comprise adders, multipliers, and the like for effecting the functionality shown in FIG. 5.

[0067] In this regard, the present invention has been described with respect to a particular illustrative embodiment. It is to be understood that the invention is not limited to the above-described embodiment and modifications thereto, and that various changes and modifications may be made by those of ordinary skill in the art without departing from the spirit and scope of the appended claims.