|
The server side of live streaming, (our end), is fairly simple. Our streaming servers simply accept the feed that you are pushing to it, or monitor for the feed if in pull mode, and make it available to those who connect to your publishing point to listen or view. Our streaming servers generally run at less than 5% CPU utilization on average, and there is very little that can go wrong on the server side during streaming. The problems that arise are typically due to poor network routing at the time of your broadcast, (whether on the listener side or yours), or the upload speed of your internet connection being too slow for the bitrate(s) at which you are broadcasting. Here are some things to investigate if you find yourself experiencing poor broadcast performance: Ensure your bitrate is not set too high The bitrate at which you broadcast must not exceed the upload speed of your internet connection (not your download speed.) To get an idea of your connection's upload speed, perform a speed test, from the same computer you use to encode your broadcast, at http://www.speedtest.net. The speed test will measure both your download and upload speed. Pay no attention to the download speed, which is generally higher than your upload speed for Cable or DSL users, as it has no impact on live streaming. Look at the upload speed instead, and compare it to the bitrate you choose when running Windows Media encoder. If the bitrate you use for encoding is higher, you'll have problems. If you are encoding to multiple bitrates, for example to support both dial up and broadband users, add the bitrates together and ensure that the total of all bitrates does not exceed your upload speed. Also, since network conditions can be constantly variable, run a few speed tests to see if your upload speed is fairly constant, or fluctuates. Allow for that in your bitrate choice (i.e. make it low enough that it is lower than the lowest upload speed you record during your speed tests.) Finally, consider whether or not there are any other applications in use during the times you broadcast that might be consuming upload bandwidth. Most internet use involves typing addresses in your browser or clicking links, which uses very little upload bandwidth, and mostly download bandwidth. These types of activities should not pose a problem, but if anyone else who shares your internet connection is upload files to a location outside your network, that is going to interfere with broadcasting. Check for routing issues Once you've determined the bitrate(s) used for broadcasting are not going to be problematic, the next step is to look for possible internet routing issues between your location and our media server. You should know the media server name or IP address to which you are broadcasting. Consult your instructional email or open a ticket if you don't know either of these. Then, run a simple ping test, from a command prompt on the system doing the encoding, that will give you an idea if there is any packet loss: ping -n 100 [servername] Replace [servername] above with the actual name or IP address of the streaming server to which you broadcast. When you run the command, it will perform 100 pings to the media server, and afterwards will display a summary which looks something like this: Ping statistics for 75.126.19.38:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 45ms, Maximum = 55ms, Average = 50ms If the summary shows a packet loss percentage greater than 2%, that could be the source of the problem. To narrow down where the packet loss is occurring, you should run the following command, also from a command prompt: pathping [servername] Again, replace [servername] with the actual server name or IP address, and then provide the complete results to us in a support ticket. We'll see if we can get with the responsible party for a resolution, depending on where in the route the packets are being dropped. Audience members may have the same routing problems Aside from routing problems between your network and ours, audience members can have similar problems. If you are having problems that seem to be isolated to only certain audience members, have them run a speed test to ensure their download speed is greater than the bitrate of your broadcast, and also have them run the ping test as well to determine if there is any substantial packet loss between them and the media server. Have audience members check their WMP configuration One final setting on the audience member side that can sometimes cause problems is the Connection speed setting in Windows Media Player. If you have an audience member who is having problems receiving your broadcast, particularly if you are broadcasting in multiple bitrates, have the audience member access Tools -> Options -> Performance in his or her Windows Media Player, and ensure the Connection speed setting is set to "Detect connection speed (recommended)". This allows WMP to test the network connection when it connects to your stream, so that it can pick the best bitrate for the current connection. None of the above? If you've been through all of the above and have ruled them all out as likely reasons for your problems, please open a support ticket and request that we monitor your next broadcast, and we'll see if we can assist you further in narrowing down the problem.
| 
