Methods of Distributing Live Streams

Pull From End Users

In its simplest form, the Windows Media Encoder simply allows users to connect directly to it and distribute the stream to them. This rarely works for more than 1 or 2 viewers.  In our six years of streaming, we have NEVER used this method to distribute a stream.  

Connecting directly to the encoder computer requires the encoding computer to have enough bandwidth to deliver a stream to each individual user.  

Advantages;br>If the encoding computer does have a public IP address and does not have a firewall, this method is a simple solution to allow one or two viewers to view a stream.  For example, this may work well for monitoring a security camera remotely.

Disadvantages
Requires either a pubic IP address or requires users to be on the same network. Most facilities such as hotels or convention centers will not provide a public IP address.  In addition, if they do, getting them to open holes in their firewall is next to impossible.

Requires significant bandwidth.  For example, if the encoder computer is on a DSL or Cable Modem line, the upload bandwidth is typically less than 400kbits/second.  This means that, allowing for network overhead, the encoder can only stream 320kbits of video.  This could be (2) 160kbit streams, or (1) 170kbit stream up to a maximum of 320kbits.  In fact, a T1 line will only handle (4) 300kbit streams.

Encoder Only Diagram

Streaming Media Providers

Adding a streaming media provider such as Internet Video Channel bypasses the massive bandwidth requirements for the encoder computer.  When using a streaming media provider the encoder only needs enough bandwidth to get one steam to the provider.  All end users connect to the provider to view the stream.  For example, Internet Video Channel has access to basically unlimited bandwidth.  At all times we have access to hundred’s of megabits of data.  With a few hours notice, we can scale to gigabits.  

Provider Pulls Content From Encoder

Before Windows 2003 Server, the only method for streaming with a provider was to have the server pull it from the encoder.  With this method, the server did not receive the stream until the first user requested it.  At that time, the server would connect to the encoder and pull the stream to it where it would then be distributed to everybody requesting it.  This method worked well until Firewalls started getting in the way. 

Advantages
Pull doesn't waste bandwidth.  With Pull, no signal is being sent to the server unless somebody wants to view it.
Providers typically have significant bandwidth. Providers can typically meet all bandwidth requirements and deliver jitter free, high quality streams. 

Disadvantages
Like the "No Provider" option above, this requires a public IP address, as well as open ports for the connection to be established.  These requirements are becoming increasingly difficult to meet. 

Provider Pull Diagram

Provider Pulls Content From Encoder

Windows 2003 Server introduced PUSH technology.  With this method, the encoder sends the stream to the servers.  This allows the encoder to establish the connection on port 80 (the web port that is always open).  Once this connection is established, additional network ports are able to be opened since the Encoder established the connection, not the server.  Since we installed our 2003 Servers, we have rarely done a pull webcast.  

Advantages
Easy to connect to the provider.  There are no requirements for open ports, or public IP's.  In addition, firewalls do not get in the way. 

Disadvantages
Live streams that have no viewers are still utilizing bandwidth.  From a provider point of view, it is possible that all of our bandwidth could be utilized with no viewers.  However, that is more theoretical than practical.  There really aren't any other disadvantages of Pushing a stream.

Push to Provider Diagram