My last blog post was a long tirade on the poor video streaming during and surrounding the Apple iPhone 6 launch event on September 9th. If you read that post, you may be wondering what else there is to say. But I assure you, because Apple’s live streaming went so spectacularly wrong, there are many more lessons we can learn from it.
In his blog on Streamingmedia.com, Dan Rayburn, discusses some of the issues Apple had with their streaming. Based on his analysis, and others he references, I’ve pulled out what I think is the main lesson learned for anyone planning to use live streaming:
Test the final web page with a live feed before your event.
Now, that may be an obvious statement to some. I certainly would think it was for a company like Apple who uses live streaming for these events every year. Now, I obviously don’t know what Apple did in preparation for the iPhone 6 launch event, but I’m going to go out on a limb and make some assumptions in order make sense of it all.
According to Mr. Rayburn, there was some code added to the page where the live video would be streamed. The code included adding a live Twitter feed to the webpage below the video. Without getting too technical, this code caused a major problem with how the video was delivered via Apple’s CDN.
Other issues involved Apple improperly configuring its storage on the Amazon cloud server. Their encoder was set up incorrectly (resulting in 27 minutes of Chinese audio translation for everyone), and the video player reacting to the previously mentioned code by degrading bit rates to match the high update rates.
Basically, a lot went wrong. To me that’s a signal one part of Apple was not fully communicating with the other.
For example, the website folks thought it would be a great idea to add fresh Twitter feeds every few seconds. They added the code to the page unaware of how the video player would be affected.
Apple encodes their live events on site (again according to Rayburn), and whoever was in charge of that either accidentally used the wrong settings, or inadvertently changed the settings while trying to figure out what was going wrong with the live video feed.
So the website people did their thing, the video people did their thing, and neither understood the impact it would all have on the final result. I’ll say again, this is all just speculation on my part based on similar catastrophes I’ve seen on other projects in my corporate experience and in the public eye.
One example that comes to mind has nothing to do with video streaming, but does highlight how bad things can get when teams don’t communicate with one another. Back in 1999, NASA’s Mars Climate Orbiter spacecraft crashed into the surface of Mars because one engineering team used metric units and another used imperial. When it came time to land, the difference between feet and meters made it slam into the surface instead of a gently coming to rest on the surface.
Apple’s live event crashed on thousands of web pages that morning. And your live streaming event could crash too.
What can you do to avoid it? You should of course have a process in place for video production and streaming that works in tandem with your website design team. But even then, errors happen. The only way to be sure is to test stream a live feed to the actual web page that will be used for viewing the event.
Ideally you want as many people and devices testing the stream as you can. Perhaps offer a pre-show a few days earlier, or related video your target market would be interested in seeing. You just need to generate enough data to know how your web page and video will function during the live event.
Communication and testing can make the difference between a successful live streaming event and one that fails to impress anyone.