Our streaming keeps buffering, what can I do?

Rebuffering is often caused by poor routing between the location of your encoder and our data center, or between the streaming viewer and the data center. It can also be caused by not having enough upload speed on your internet connection for the bitrate at which you are encoding, or by exceeding the available bit rate or overtaxing your encoder when combining broadcasting with video recording.

If you encounter frequent rebuffering of your streaming, here are the steps you should take to troubleshoot before opening a support ticket:

Make sure you enable auto-adjust and set it to degrade quality

In the event that any of the below issues affect your ability to push data to the streaming server, you want your encoder to be able to auto-adjust to keep the stream going. It's best to degrade quality rather than drop frames. in Adobe FMLE these settings are located on the right hand side of the encoder window under the section where you specify your FMS URL.

Check your bitrate

If you find your encoder frequently disconnects and then automatically reconnects, you could be exceeding the bitrate limit for your streaming plan. This might appear as frequent stopping and starting in your player. The advertised maximum bitrate on your streaming plan is a limit (there is a small additional percentage allowed for bitrate fluctuation) that our servers will enforce if you exceed it.

Determine your upload speed

First, make sure that your internet upload speed is sufficient for the bitrate at which you are broadcasting. To do this, visit a speed testing site such as http://speedtest.net, and run at least three tests, then average them together. Make sure the average speed is greater than the bitrate at which you are broadcasting. If not, you'll need to bring your encoding bitrate down.

Be aware that your upload speed can also be consumed by other activity on your network. It is recommended that before you begin streaming, you power cycle your internet router or modem by unplugging it and then plugging it back in, to reboot it and give it a fresh start. This can also help ensure other network activity that is using your upload speed is halted (though it's possible it may resume depending on the nature of such activity.)

Check for packet loss along the route

If you are using a Windows system to encode, or have a Windows computer on the same network as the encoder, there is a handy pathping command you can use to thoroughly check the routing between your location and us. To us this command, open a command prompt, (Run -> All Programs -> Accessories -> Command Prompt), and run this command:

pathping s#.streamcp.com

Replace with the # with the number of the streaming server you plan is on.

This command will run for several minutes, and will eventually produce a summyar that looks something like this:

Copy the complete output and paste it into a support ticket and we'll see if it indicates packet loss. If so, you'll generally need to contact your ISP and provide them with the evidence of packet loss so they can work with the affected network hop to clear it up.

Packet loss can be intermittent, so please run at least three pathping commands and provide complete output from each to us.

If you are on a Mac, the pathping command is not available, unless you can run Windows via Bootcamp, Parallels or VMWare Fusion. If you cannot access the pathping command, run these two commands instead:

traceroute s#.streamcp.com

ping -n 100 s#.streamcp.com

The output is not as detailed, but still may help reveal packet loss.

Is your encoder up to the task?

Finally, ensure that your encoding system is not being overtasked. If you are both streaming and recording the broadcast at the same time, the load on your encoding system could result in encoder disconnects and/or random distortions or drop outs in the recorded video. For example, troubleshooting with a client recently who was broadcasting live with Wirecast, and recording to Apple ProRes 422 at a higher bitrate for later video editing, revealed that his system was simply unable to handle both jobs well. The client was able to switch to a different video format for his recording which didn't tax his system as much, and his live broadcasting trouble went away.

Is your encoder wireless or wired? (Wired is better)

It's definitely best that your encoder be connected via physical ethernet cable to your network, not via WiFi. There are so many radio signals that can degrade WiFi throughput that even though your ISP is providing good upload speeds, your WiFi connection might not consistently provide those speeds from your encoder to the internet modem/router.

Are you allowing public use of WiFI connected to your network?

It's also far better to NOT have public use of your network via WiFi while you are encoding. For example, sometimes churches will allow a congregation to connect to their network via a guest WiFi access point. This is not a good idea, as you cannot guarantee that usage won't interfere with bandwidth available to streaming. Additionally, you would be surprised at how many computers have hidden malware their users aren't aware of, that will launch attacks through your network and cause your network IP to be blacklisted.

Allowing guest WiFi use of your primary internet connection is a bad idea all the way around. If you must, consider installing a secondary internet service for this to avoid disruption to streaming and other important connectivity the church may need for day to day operations.

If the above does not help, contact us for troubleshooting assistance

If you have been through these troubleshooting steps and have not been able to identify the problem, please open a support ticket and we'll be happy to help you troubleshoot.