You can easily estimate bandwidth for two different types of applications: a one-to-many application, such a video-on-demand system; and a many-to-many application, such as a video conferencing application. For each example you can follow a simple formula for calculating both the server bandwidth (required to determine the number of software licenses you need) and the client bandwidth (calculated as part of your bandwidth strategy to ensure good quality of service to each client).
This sample application is a one-way video-on-demand system that streams recorded video at the user's request. Flash Media Server serves only one stream to each user (see Figure 1).

Figure 1. One-to-many video-on-demand system
Here are the bandwidth calculations you would make:
Calculate the overall server bandwidth needed to stream video encoded at 500 Kbps to 1000 simultaneous users:
500 Mbps = 1000 × 500 Kbps
This calculation determines the overall bandwidth and can help you determine how many servers and licenses are needed. For example, if your server hardware configuration is capable of 600 Mbps throughput, you would need only one server and license.
Of course, if you wanted to stream to more users, you would need as many servers and licenses as are required to cover your overall server bandwidth. For example, 10,000 simultaneous users will require the following:
5000 Mbps = 10,000 × 500 Kbps
Assuming each server configuration is capable of 600 Mbps, you would need:
8.3 = 5000 Mbps ÷ 600 Mbps
This rounds up to nine servers and licenses.
The preceding calculations assume that content is encoded at a constant bitrate. Most often, however, you will vary the bitrate of the content to suit the viewing audience. This affects your bandwidth needs at both the client and server level.
For example, suppose in the previous example you estimated that half of the 1000 simultaneous users were going to connect via 350 Kbps DSL modem and the other half via 3 Mbps cable modem. Suppose further that while the video encoded at 500 Kbps was appropriate for the cable viewers, you wanted to encode a separate video at 150 Kbps for the DSL modem users.
In this case, the total bandwidth required of the system is lowered to 325 Mbps:
325 Mbps = (500 Kbps × 500) + (150 Kbps × 500)
This example shows a number of people connect to an online conference room. While in the conference room, each person is broadcasting their own audio and video (via a webcam, for example) while receiving the audio and video broadcasts from others in the room (see Figure 2).

Figure 2. Many-to-many video/audio conferencing
Calculating the bandwidth estimates here is very similar to Example 1. However, the number of streams increases exponentially. In this case, Flash Media Server needs to serve x2 number of streams where x is the number of simultaneous users in a room.
For example, if there were four people in a room, the first person would send (publish) one stream and receive three other streams for a total of four streams. Likewise, the second, third, and fourth persons would also consume four streams each. Therefore the total number of streams that Flash Media Server serves in this case is 16—four people using four streams each, or (thought about in a slightly different manner) four publishers of streams and four consumers or subscribers of streams.
Here are the bandwidth calculations you would make:
Server bandwidth needed for a four-person webcam chat using 100 Kbps streams:
4.8 Mbps = (4 × 4) × 300 Kbps
Client bandwidth needed for a four-person webcam chat using 100 Kbps streams:
900 Kbps = 3 × 300 Kbps downstream
300 Kbps = 1 × 300 Kbps upstream
How many users can you support on a single server? In this example, each video conference room generates a bandwidth of 4.8 Mbps. Again assuming 600 Mbps server machine throughput, you can have 600 Mbps ÷ 4.8 Mbps = 125 rooms. Because each room has four participants, you can get 125 × 4 = 500 simultaneous users on one server.
This example illustrates another important aspect of Flash Media Server: there is no limit on the number of streams it can serve. Each user of your application (or, said another way, each connection) can publish or subscribe to an unlimited number of streams as long as the total peak bandwidth-per-second limit is not reached.