The first of these steps is to capture your media. In order to do this, you will need an input device for your computer. For audio content, the input device can be a text sound card. For video content, you will need some type of video capture device.

Examples of typical video capture devices are a firewire port (firewire card) or a video capture card. Common video capture cards that we know work are the Osprey 220 from ViewCast or capture cards from Winnov or Pinnacle.

An encoding station is simply a computer that runs encoding software (the "encoder") that converts your captured media to a streaming format. Most encoders require a reasonably fast computer to run. Normally a Pentium II with at least 128 MB of RAM is good if you're a PC user but, as always with computers, faster is better. Typically, We recommend that you use the encoding software that is provided by the manufacturer of the streaming format you have chosen. That is if you are a Windows user broadcasting a live Windows Media stream, we suggest you use the Windows Media Encoder. If you are broadcasting your content in RealMedia format, please use the newest encoder available for your operating system. For QuickTime Streaming we suggest the QuickTime Broadcaster for Mac OSX.

During a live streaming media broadcast the encoding software (the encoder) takes the data from your input device and converts it to a streaming format. Depending on the streaming platform (Windows Media, RealMedia or Quicktime) the server either "pulls" (contacts the encoder and requests the stream) or the encoder "pushes" (sends the stream to the server IP address) to rebroadcast the live stream. When the encoder converts the stream, it "buffers" (saves a certain amount of the stream data on the encoding work station) before the stream is distributed for rebroadcast through the servers in our data centers. This creates a certain amount of "latency" (lag time between the actual event and when your audience member sees it.) There are two other sources of latency during a live streaming media broadcast. The time it takes to get the stream across the Internet to our servers and the time it takes your audience member to receive the stream across the Internet. These vary according to the position of your encoding station on the Internet and the position of the computer of each of your audience members.

When you set up your stream for live broadcast, you must specify the bit rate (quality of the stream). This quality is constrained by the upstream bandwidth of your Internet connection and cannot exceed this limit or your stream will never reach our servers. Along the same lines, your audience member must have enough downstream bandwidth to allow all of the data from the encoded stream to play on their computer. If the encoded stream you are sending for rebroadcast exceeds the downstream bandwidth of your audience member, they will never receive the stream.

Depending on how the servers are setup they will deliver the media stream in one of two ways. Either as a push configuration where servers are continuously sent a stream from the encoder, or in a pull configuration. A pull configuration makes a connection and "pulls" the stream when a player connects to it. Regardless of which configuration is being used (the Windows Media Server uses "pull" while the RealServer and Darwin Server for QuickTime use "push".) Once the feed is acquired on the inbound streaming server it is re-distributed throughout our two data centers via load-balancing.

When you set up your account, we send you a link to access your broadcast through our globally load balanced easy link system and you put this link into the HTML of your Web page. when someone visits your Web site and clicks a link for streaming audio or video, that request is directed to the data center closest to them and they stream your live broadcast through our servers.

By directing your audience member to the closest data center, we cut down on the time it takes to deliver your stream to them. Once the closest data center has been established, the streaming request is sent down one of the many backbones we are connected to via Internap's advanced "Synchronous-When-Optimal" routing service. Our system delivers your media by avoiding the often congested public and private peering points of the Internet, thus greatly increasing delivery performance and reducing problems such as rebuffering.