Streams fall apart
You’re all setup ready to start streaming. Wirecast Preview looks excellent. Everything’s behaving as it should. You’ve even done a quick test recording to your hard drive with your encoder settings and you’re happy with the results.
You’ve set up the stream coming from your CDN on another computer so you can see what your viewers will see. You start Broadcast and then . . . the stream is blocky, there are long moments where the video is frozen, things move in fits and starts, lots of dropped frames, maybe you’re even getting disconnect messages from the server.
Panic sets in and you’re wondering if maybe something in Wirecast or your Broadcast settings as gone awry. Maybe your computer isn’t up to the encoding task you being to think. You swear it can’t be your ISP at issue (Internet Service Provider) because you’re paying for a “10Meg” service.
When ISPs market their speed they often only note the download speeds. They assume most are consumer rather than content creators. The upload speed is often significantly less. So how do we unravel the riddle of what’s going wrong?
Check the specs
Check the complete provisioning docs from your ISP. Make sure you see both the download and upload specs. Download impacts your ability to view a stream. Upload impacts the ability to send the stream. Each ISP offers different combinations ranging from symmetrical (down and up are the same) to upload speeds which are one tenth the download or smaller. You’ll usually find the upload spec significantly lower than the download. You may be provisioned for 10Mbps down but only 768Kbps up.
Check the speed
What those specs say may not be what you’re actually getting in the real world. More often than not, what you’re actually getting is different. One of the most well known and reliable sites for speed testing is speedtest.net. Click on “Begin Test” and they will report download, and upload speed, as well as ping time (more on that later). It will test from your current location to the server closest to you, otherwise it’ll allow you to chose another server. The speed you get for a server close by will generally be much faster than for one thousands of miles away.
Speeds lower than expected
The distance to the server you’re using may be one reason you’re getting for lower speeds. Another may be issues local to you from your ISP. It could be an issue with a local node (the place where you and your neighbors on the same ISP connect to the “super highway” via your ISP main facility). Maybe there’s a technical problem on the node or maybe it can’t handle the heavy volume of traffic at a given time of day. It can even be wiring into your location or a WiFi signal strength issue, if that’s what you’re using.
Check the stability
You may have the speed you expect, but you’re still having issues. Regardless of speed, a stream can have stability issues. Another important check is a ping test. It works similar to speed test although it may additionally ask you to allow a java app to be installed. Go ahead and allow that. It will give you packet loss %, ping time, jitter time. Even if you don’t understand the jargon it’ll give you a letter grade. Anything less than an “A” means you may have issues ranging from minor to major depending on the letter grade. A “B” might be survivable but you can have issues. Anything lower is going to be a serious problem. For the geeks amongst us, the individual results are as follows:
Packet Loss is bits of data (your video and audio during a stream) that are sent to the server but never arrive. Anything other than 0% means some of your stream is not reaching the server. This can result in slower speeds and pauses in the stream. This is the most egregious problem.
Ping is the time it takes for the data to go to the server and back. If the higher the number the more “sluggish” or more latency that might occur. The lower the number the better. You want a number lower than 100ms generally.
Jitter is fluctuation in time of the Ping test. 0ms means the ping test was the same for the multiple tests it ran. Jitter should be a small fraction (just a few ms) of the ping test. It means that there aren’t major time changes from moment to moment as the signal path goes full circle.
Notify your ISP of issues
If you’re getting lower than expected speeds or anything other than 0% packet loss, it’s time to talk to your ISP. Many will say they can’t guarantee a speed given that your broadband is shared, but even then packet loss should be 0%. You should send them the results of the above tests along with the exact time of the test. SpeedTest and PingTest have an easy copy feature to help you with that. If you’re savvy enough to document the issue, ISPs will generally be willing to help you improve your speed and resolve the packet loss. If the node is simply too heavily trafficked, they should be willing to “split the node” to lower traffic. If they’re not accommodating, it’s time to consider looking elsewhere.
Additionally, if you’re in the USA or Canada, there is a great host of forums for specific service providers where you can share user test results and often get direct ISP support DSLReports which, despite its name, includes everything from cable to phone to satellite providers.
Data rate is cumulative
Don’t forget that speed is cumulative. Keep your total upload streams below your tested upload speed. If your upload speed test is 1Mbps then a 700Kbps and 400Kbps is too high. Some recommend keeping the total to 80% of provisioned upload speed. Because Apple’s H.264 codec used in Wirecast can peak much higher than your Broadcast encoder settings during transitions or fast motion, I tend to target no more than 50%. Wirecast 4 will be switching to MainConcept’s H.264 which has more constant data rates, so peaks should be less of an issue in the future.
Testing to get ready
Always test run SpeedTest and PingTest before any important stream. You never know when your ISP might be having a bad day. If you do mobile streaming, always go to the site beforehand to run the tests to make sure you can actually have a successful stream from the location. Be aware that conditions can change day to day and even hour by hour and when it comes to potential node traffic issues, time of day can be critical.