This article is the fourth part of our series, 5 Things you need for a Stutter Free Webcast.

Accept that many of your users don't actually have high speed connections.

So you have a blazing fast connection, a dedicated encoder and a top-of-the-line CDN.  Now you're ready to push full res HD to your viewers, right?

Actually, your viewers tend to be the weakest link in the live webcast production chain.  While a lot of internet service providers throw around the phrase "High Speed Internet", the truth is their customers are rarely getting the advertised speeds.  In fact, a recent study by the FCC found that on average consumers got about half the bandwidth they were promised.

Still the report says the average US consumer's connection speed is 3Mbps, which would be enough to stream a pretty good HD webcast. 

There are two problems.  First, while our own numbers back that up in the US, our numbers show us that only 25-35% of viewers outside the US are capable of receiving an HD stream.  Second, if you want to maximize your audience, you can't plan for the average consumer.  That would eliminate about 50% of your audience.  To have 90-95% of people who want to watch your webcast actually see it, you need a plan to accomodate viewers with connections in the 5th-10th percentile--some pretty miserable connections.

Anecdotally, during events we've contacted viewers experiencing problems to troubleshoot and improve our system.  Poor connection speed, even on supposedly high speed DSL connections, is the number one cause of why viewers report a poor viewing experience.

Strategies

There are three strategies to accommodate the largest possible audience.  Of course, each has their trade-offs.

1. Adaptive Bit Rate Streaming.  We consider this the best method for our clients.  Using this strategy, the encoder would push several streams of different bit rates to the server.  The user's player polls their connection speed and selects the right stream for the user's connection and processor speed.  If anything changes, either improves or deteriorates, the player seamlessly switches to a more appropriate stream.
   • Pros:  This allows viewers to see the best possible stream, regardless of whether have a high-end or low-end connection.  If the connection speed changes, the player switches seamlessly between streams with no interruption to the program.  The viewer doesn't have to know anything about their connection or do anything on their own.
   • Cons:  You'll need a faster connection at your encoder because you'll be pushing multiple streams.  This method is the most expensive because it requires a custom player that is capable of doing the switching.  It's a rather new technology and while we've developed our own, we don't know of any off-the-shelf live adaptive bit rate players available that are viewable across a large array of browsers and operating systems.  (Apple has developed one compatible only with Mac devices using the latest Safari browser).
2. Manual Stream Selection.  Using this strategy, a user or player selects the stream (usually called "High" and "Low") at the time they connect to the server.  If the connection speed changes, the user must stop that stream and start the other stream.
   • Pros This method does allow you to have a high resolution stream for better connections and a low resolution stream for poor connections.  This too may require a custom player, but is a much older method and more are available.
   • Cons If the connection speed changes, either improves or deteriorates, there is no way to detect it.  If it improves, the viewer will not know they could be watching a higher resolution stream.  If it deteriorates, the viewer will know when the stream starts to stutter and buffer.  Changing streams is not seamless and will cause the viewer to miss some of the program.
3. Streaming for the Lowest Common Denominator.  If you must use an off-the-shelf player or are limited to only one stream, then this is the last option.  In this scenario, you produce one stream at a very low bitrate.  While it won't look great, at least everyone will be able to see it.
   • Pros It's the least expensive option as there are a number of free off-the-shelf players available.  It requires the least bandwidth for the encoder.
   • Cons The quality of your stream will be reduced to what's acceptable for the lowest common denominator.  In our experience, this much compression typically involves heavy blockiness and muddiness when streaming an action sports event.  The other option is to eliminate a sizable chunk of your audience's ability to see the stream.

This article is the third part of our series, 5 Things you need for a Stutter Free Webcast.

Get a quality internet connection at your event site

Even if you can view high resolution videos using your internet connection, that may not mean that your connection is sufficient for streaming a live webcast.  Here is our process to determine if a connections is "live stream ready" and if not, what alternatives exist for you to consider.

Understanding how a live webcast uses an internet connection.

When you measure connection speed, there are two speeds that you need to keep in mind, download speed and upload speed.  While it might seem logical that both would be the same at any given location, that is rarely the case.  Most often, internet service providers will provide more bandwidth for downloading than uploading simply because that is what most people do most often.

Unfortuatnely, for a live webcast, upload speed is absolutely critical.  It is what determines the bitrate you can push to your streaming server.  Bandwidth is like a pipe.  As long as you aren't cramming more stuff in the pipe than it's capacity, there's not a problem.  As soon as you do, not all the information can get through.  The result in your webcast is stuttering, dropped frames and all sorts of nastiness that you want to avoid.

Measuring your upload speed

The easiest way to measure your upload speed is by conducting a free speed test.  Select a location nearest to where your origin server exists.  Some CDNs provide multiple origin servers at various locations around the world.  By testing the speed to several locations, you can identify the server that is most likely to perform the best.

It's important to test your connection speed multiple times in conditions similar to the ones you'll be operating under.  Additional users sharing your connection will affect your connection speed.  For example, many ski resorts' POS system use the internet.  During very heavy sales, their system may cause a reduction in the available bandwidth.

Why you need to consider overhead

Even if your results are pretty good, there are number of things that can happen during your webcast that you need to take into account. 

• All encoders stream's bitrate will spike when there is a lot of action on screen.  Unfortunately, when there is a lot of action is on screen tends to be the most critical point of an action sports event.  This is one of the reasons we suggest a getting a dedicated encoder for your webcast, as they tend to have much smaller spikes.
• Increased internet traffic at any point along your route can cause a decrease in your connection speed.  Realistically, during events, there is always more demand for internet connections than you've anticipated.
• Just the way that streaming technology works means that your stream actually will have less effective bandwidth than what you've measured.

To calculate your maximum bitrate, take the worst result from your speed test and divide it by 2.  For example, if you measured your upload speed at 3.2Mbps, that means that 1.6Mbps is the maximum recommended bitrate of your stream.

Alternatives

If you discover that you don't have a sufficient connection for your desired bitrate, there are a couple options available.

1. Lower the bandwidth of your streams.  While this will cause more compression and therefore a degredation of the quality in your video stream, we consider this far better than stuttering.
2. Eliminate adaptive streaming.  Each stream takes up bandwidth in your connection.  Eliminating a stream may allow you to have enough bandwidth for the others.
3. Get a temporary high speed connection.  Some internet service providers are happy to set up a temporary connection.  If that doesn't work, portable satellite uplinks are available for rent, but tend to be very expensive.

Are you looking for other ways to improve your live webcast?  Don't want to miss out on more tips and tricks for producing better, more engaging, higher quality livestreams?  Subscribe to Adrenaline Garage's quarterly report via email today.

This article is the second part of our series, 5 Things you need for a Stutter Free Webcast.  Click here to see the first article about encoders for live webcasts.

Get a quality CDN

While a quality CDN is a ciritical link in a seamless webcast, I’m not sure that most event organizers understand what it is, how it can affect their webcast and why some CDN’s are better than others.  Let’s get right to the ugly technical part.  Wikipedia defines a CDN as,

A content delivery network or content distribution network (CDN) is a system of computers containing copies of data, placed at various points in a network so as to maximize bandwidth for access to the data from clients throughout the network. A client accesses a copy of the data near to the client, as opposed to all clients accessing the same central server, so as to avoid bottleneck near that server.

I’m sure we’ve all seen the chaos of doing a product toss in a large crowd in a small area.  People rushing in, throwing elbows, grown men crying.  It can get ugly.  Now imagine what would happen if you distributed product tossers around the venue. Rather than everyone rushing into one location, smaller crowds would gather at different locations, spread over a larger area.

A CDN does essentially the same thing.   When there is a large demand over a limited time frame for a single file (a live webcast), the CDN reproduces the stream at many different locations to allow more people easier access and tries to eliminate “fights” over the content.

A common mistake that gets made when selecting a CDN is choosing one based solely on bandwidth costs.  This could lead to nasty problems during the event. Small CDNs may perform well when there is limited traffic or the traffic is distributed over a long period of time.  However, if the traffic exceeds the capacity of the CDN to meet that demand, users experience buffering, lost connections and other mayhem, all things that severely affect the webcast experience.  Unfortunately, this problem won’t reveal itself until it’s too late, when there is the most demand for your webcast.

To counter this problem, you need a CDN large enough to handle your traffic.  A good CDN has many servers distributed around the world.  By having more locations, they can better distribute access to these points and ensure than no bottleneck occurs.  This guarantees that the capacity is there to handle the demand precisely when your event is progressing the sport to the next level.  And everyone logged on will have a quality stream the whole time.

Next up, how to find out how much bandwidth you have at your event site and how that affects your plans for your live webcast.

Since we originally published this article, it has become the most viewed post on our blog.  Since then, we've done more investigation into HTML5 and discovered a number of nuances that we weren't aware of at the time.  In the interest of providing the most clarity and current information for the new readers continually discovering this article, we decided to edit it rather than post a new one.- JH December 20, 2010

The HTML5 hype

In the past few months, we've had a number of people tell us that the technology we use for our player and streaming video, Adobe Flash, is dead.  HTML5 is the new streaming technology on the block and all the cool kids have signed on.  We should dump our old Flash based player and scoring system and start writing HTML 5 code today.  If we insist of delivering webcasts using a Flash player, we're signing our death certificate.  If Steve Jobs says so, who could possibly disagree?

Well, we did.  It just didn't make sense.  New technologies take a long time to penetrate the market and become standard.  Old technologies take a long time to disappear.  We still see IE6, a browser released in 2001, pop up in our analytics reports (in about 1 out of every 200 visits as a matter of fact).  How was something so new going to turn Flash into a dinosaur overnight?

There seemed to be an awful lot more hype than rational thought going on.  Just because "everyone is doing it" and it was the latest fad, we didn't think that was necessarily the best reason.  Someone needed to stop the hype train and ask, "Is HTML5 a superior technology for our customers that necessitates serious new investment?  How does one define superior technology?  And, is everyone really using HTML5?"  

First, Some Background

The problem all started when Apple announced that it wouldn't support Flash on its iOS devices (iPhone, iPad, iPod Touch).  Rather, Apple said it would support a new technology, HTML5.  Since those were the hot devices in the news, developers who didn't want their clients to think that their sites and apps were incompatible, immediately freaked out and started jumping on the HTML5 bandwagon.

Finally, Some Real Numbers

Then, Jan Ozer, one of the foremost authorities on streaming media, posted an article on his blog entitled, The Five Key Myths About HTML5.  He comes to the conclusion that the value of HTML5 is that it forces you to, "encode in more formats that offer no advantage over H.264, and play on fewer computers, and distribute your on-demand video with less quality of service, fewer features and less ability to monetize than you can with Flash or Silverlight. Oh, and forget live."

Forget live?  Whaaat?  But Uncle Steve told us his Jesus phone (and all related technologies) was the very bestest.

Seeing as how we own an iPhone/iPad streaming solution, we were a little shocked too.  Time to get a second opinion. We tracked down more information about live streaming with HTML5 over at the Longtail Blog, developer of perhaps the most ubiquitous video player on the web today.

HTML5 does not specify a streaming mechanism yet. While this is being worked on, it means that live, DVR and long-form video content cannot be played using a video tag.

It turns out that without an agreed upon standard for web video, each vendor has gone ahead and come up with their own solutions. While each solution uses the HTML5 <video> tag, the respective browsers are each only compatible with a different video codec.

As you can see, there is no one perfect video codec.  Depending on the browser your users select to view your video, they will require a different codec.  Moreover, the above chart is only concerned with video on demand.  For LIVE video, there is even less support, e.g. Chrome does not support live h.264 streams, but does support live WebM streams.  It's also interesting to note that Internet Explorer currently supports no HTML5 video, live or on demand, yet it is the most commonly used browser in the world.

Yes, but is HTML5 Superior?

While the proponents of HTML5 have a number of reasons, we have a singular goal: To deliver the most robust and widely accessible webcasts on the planet.  Following that logic, we believe that the most important consideration for events is making their stream compatible with the largest possible number of devices.  In our mind, the emergence of iOS devices (iPhone, iPad) and Apple's refusal to allow compatibility with Flash is what created this hype around HTML5 in the first place.

Assuming that the performance of each technology is similar (to which Ozer says Flash has an edge), compatibility should then be the primary consideration for determining superiority.  With all the press surrounding the iPhone and iPad, surely events without an HTML5 strategy would be missing out on a huge percentage of viewers.  We needed to find out which technology, Flash or HTML5, is compatible with the most devices?

According to the Ozer, if you encoded multiple HTML5 streams, you would still only be able to reach the 40-50% of browsers that are HTML5 ready.  Using only one codec decreases compatibility further.  

Aside from the hassle, encoding multiple streams creates other problems.  Each encoded stream consumes encoder capacity, which in turn requires more encoders.  In order to reach 99.5% instead of 40-50% of devices, you would need to encode at least 3 streams (Flash, WebM and h.264).  Using dynamic streaming with three bitrates, you would have to encode 7 streams and use multiple encoders.  In addition, more streams require more bandwidth.  Using a moderate bitrate to reach the most possible viewers, an event would require at least 2.4Mbps, which is significantly more than a T1 line can handle.  Encoding HD streams with dynamic HTML5 streaming would require at least 10Mbps upload capacity and 16Mbps to be safe.  While it is possible, that much bandwidth at a location is rare.  Therefore obtaining sufficient bandwidth could significantly increase the cost of an event.

This is a lot of trouble when Flash works perfectly well on 98.8% of computers.  iOS devices only make up only a little over 1% of overall web browser traffic.

It seems to us that, in addition to many complications related to encoding, the cost, the lack of features and relatively worse user experience associated with HTML5, dumping the majority of your audience to capture the small percent of iOS users is pretty foolish. 

Maybe Flash Isn't Dead on Mobile Devices

In September, Adobe released Flash for some Android phones.  Around six weeks later, Flash had been installed on 1 million Android devices.  As more and more devices have become compatible, the install rate has accelerated.  In other words, Flash webcasts are possible on mobile devices.  Actually, we've been testing Flash on Android devices since the beginning of August. 

In the most interesting test to date, we streamed an unmodified webcast to our out of the box player on our Droid.  It worked perfectly and I have to say, performance was impressive.  While the video was not as smooth as you would see on a desktop, there were very few dropped frames and the battery life seemed no different than when using the browser normally.  We were even able to log into and use our chat module.  Pretty incredible considering that we did nothing out of the ordinary to make the webcast compatible with the phone.

Our Conclusion

We definitely believe HTML5 penetration in browsers will grow.  We also believe that you shouldn't ignore iOS devices.  Our belief is that at this time, with Flash compatibility on almost 99% of devices, including a growing number of mobile devices, the time, expense and complications associated with using HTML5 as your primary video technology aren't worth it.

Our recommendation is that clients should still offer the complete experience via Flash.  In addition to the widest compatibility, it offers the most comprehensive feature set.   As the most popular streaming solution available and an extensive amount of software and hardware already developed, it will be much cheaper.  

If you are interested in reaching users on iOS devices, we suggest creating one HTML5 stream and a simple player until HTML5 becomes a much more mature technology.

How would you compare Flash and HTML5?

"My piss has a stronger stream." - tits hemmingway

When things go wrong during a live action sports webcast, online audiences feel no inhibition about getting poetic.  Something about the anonymity of the web combined with stuttering video creates heartless little creeps who have no sympathy for the unyielding complexities of live events.  However, while dipping into their proverbial French vocabulary for four letter words, sometimes the audience manages to pull off a metaphor worthy of Shakespeare (or more likely, David Mamet) such as this eloquent (some might say Hemingway-esque) beauty left in the comments of one of our competitor's webcasts.

We know that this unfortunate outpouring of creative energy, enough to make a longshoreman cringe, can be avoided.  In our experience, there are a few key factors that seem to be at the heart of most of these horror stories.  Knowing that this is the fear of event organizers around the world, we thought we'd put together a brief checklist for how you or your provider can ensure a smooth live stream.  Mastering these, like we have, enables you to kill the muse for your viewer's inner online poet.

Get a dedicated encoder

In action sports, every frame counts.  Drop a couple of frames and in that split second, a 1080 is indistinguishable from 360.  To make things worse, during a 1080 is when your encoder is most likely to drop a frame or two or 20.  It's not Murphy's law at work, it's just the way the technology has been built.

In order to squish that huge amount of information from your massive HD video stream (that you've paid tens of thousands extra for) into your viewer's tiny internet tubes, you need compression.  Video compression means looking for similarities between video frames and throwing out the redundant info.  It's not too hard on a compressor when it's a lock down shot of a talking head with only a moving mouth.  Throw a panning, zooming double cork at it where every pixel changes, and you've just overloaded your encoder.

Your free encoder (ahem, Adobe Live Media Encoder, we're calling you out) that works just fine for corporate stockholder meetings can do one of two things when faced with more information than it can handle.  It can either push out a bandwidth spike in your stream or drop frames.  (ALME likes to do both)  Either one of these will cause problems, as we will explain.

The solution?  Tell two-time X Games Gold Medalist Bobby Brown he can only do straight airs all the way down the course.  But seriously, get a dedicated encoder with plenty of overhead so it can handle those double and triple corks.

How do you know your encoder can handle it?  Stream your favorite action sports DVD.  When you like the results, keep the encoder (or the provider).