Let’s talk briefly about the two Windows Media® streaming methods, known as Pull and Push. Choosing the best method for your needs is important. Let’s review each, and consider what is best for your needs.
Pull by End Users
Simply put, the Windows Media Encoder® in TriCaster allows your (networked) audience to connect directly to it, and it distributes the stream to them.
Connecting in this manner requires you to have a connection with sufficient bandwidth to deliver a stream to each individual user. For this reason, the simple Pull streaming method rarely works well for more than 1 or 2 viewers.
- When TriCaster is not behind a firewall or does not have a public IP address, this is a very simple way to let a few viewers watch your program stream.
- Requires either a public IP address or requires users to be on the same network. Facilities such as hotels or convention centers will usually not provide a public IP address. Even if they do, getting them to open holes in their firewall is next to impossible.
- If TriCaster is behind a router, your router must be configured to ‘port forward’.
- Requires significant bandwidth -- for example, with TriCaster connected to the Internet by a DSL or Cable Modem line, upload bandwidth is often less than 400kbits/second. Allowing for network overhead, at best a 320kbit steam can be accommodated. This bandwidth would be fully consumed by two viewers watching 160kbit streams, or a single viewer pulling a 170-320kbit stream. (Even a T1 digital line can only handle four simultaneous 300kbit streams).
A variation on the Pull method involves using an external streaming provider. At one time the only method for streaming using such a provider was to have the server ‘pull’ it from the encoder. Under this system the server did not receive the stream until the first user requested it. Then the server would connect to the encoder, pull the stream to it, and finally begin re-distributing it to everyone requesting it. This method worked passably until firewalls became more common.
- Pull doesn’t waste bandwidth; no signal is being sent out to the server unless somebody wants to view it.
- If you lose your connection to the (provider side) server, the server will re-connect to your encoder automatically when Internet connection resumes.
- Providers typically have significant bandwidth, and are able to meet necessary requirements to deliver stutter-free, high quality streams to large numbers of viewers.
- Like the “Pull by End Users” method above, this requires a public IP address, preferably a “static IP address” (which does not change dynamically if you need to reconnect) as well as open ports for the connection to be established. These requirements are becoming increasingly difficult to meet (given common security measures).
Push To Provider
Windows Server2003® introduced “Push” technology. With this method, the encoder sends the stream to downstream servers. This allows the encoder to establish a connection to the server on a specified port. Once this connection is established, additional network ports may be opened as required (since the Encoder established the connection, not the server.)
- Easy to connect to the provider. There are no requirements for open ports on your local system, or public IP’s. In addition, firewalls do not get in the way.
- Live streams that have no viewers are still consuming 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.
- Some external streaming providers prefer to Pull streams, as re-connection can be performed from their end automatically if necessary. But in many venues system administrators are very reluctant to configure their system with an open port to have your stream Pulled from.
For more information please download the entire document at new.tk/rt-m