Why Flashless Streaming Sucks Posted:

Warning – the following article is pretty technical. You should probably skip it if you’re not interested in the ins-and-outs of video streaming!

Hey guys;

So I was in a stream today, and I was talking about different streaming protocols and basically why the “Flashless” stream protocols suck.  It’s an item of general interest, so I figured I would share it.

How Flash Streaming Works

If you use Flash to watch a stream, you’re using a protocol owned by Adobe called RTMP.  RTMP is a means computers talk to each-other, and RTMP is optimized for Live Streaming.  It’s actually a very complex protocol that tries to keep its clock in sync with the servers, in such a way that if your stream lags behind (due to network problems or whatnot), the protocol has a way to “fast forward” and re-sync the stream.

This is a pretty ugly thing and sometimes causes the weird graphical breakups you may see (“artifacts”) on the stream or brief audio outages.  However, it’s pretty rare that a stream cuts out all the way.  The typical worst that happens with a Flash stream (assuming Flash isn’t crashing on you), is you get an accumulation of break-ups that cause your stream to get further and further out of sync with the server, which increases the perceived “delay” between what the artist does and what you see.

However, generally speaking, this is about as good as it gets.  The truth is, there’s a lot of Internet between you and the server and its impossible to have perfect quality all the time.  RTMP is built to give you the best odds at an enjoyable, watchable stream experience.

By the way — if you’re wondering how Netflix is always smooth as silk and never glitches out for you but streams sometimes do, it is because serving static video in a seamless way is a much, much easier problem to solve and very different from live streaming. The details of why are rather out of scope of this little article, though, so please take my word for it!

How Flashless Streaming Works

So, at the top of this article, I boldly pronounce that Flashless Streaming Sucks.  Why do I say that?  Here are the big reasons:

  • Built-in delay; it is almost impossible to reduce a Flashless stream’s delay (time from the artist doing something to you seeing it) to under 30 seconds without sacrificing reliability.  If you sacrifice all reliability, you’re still going to have a 10 second delay, there’s no way around it.
  • Forced trade off; with Flashless streaming, you either reduce delay or you reduce the chance of a stall (stream freeze).  You can’t have both, and yet having both is critical to a good user experience.
  • More chance of stalling.  There’s basically no error recovery.

These problems are inherent to how Flashless streaming works.  But, Google has forced Flashless down our throats with Chrome aggressively disabling Flash, and Flashless streaming is required for mobile which is an increasing use case.

Let’s get into how it works!

There’s two Flashless “protocols”.  They’re not really protocols; under the hood, both of them use HTTP or HTTPS (web protocol) so they’re both really making a series of web requests.  RTMP is a protocol because it operates on a lower level; it’s a basic language of communication, just like HTTP.  HLS and DASH (Flashless) are protocols on top of HTTP, so to begin with they’re kind of a kludge.

How both of them work, is they take a stream and they cut the stream up into many static files.  So, instead of a constant stream of video like RTMP,  we’re actually taking the video and cutting it into little pieces.  The size of the piece is configurable by the server, but it has to be fairly large; on the order of 5 – 10 seconds.  The reason it needs to be large is because we need time to download the next piece while the piece we’re on is playing.

The server writes a play-list file, and the play-list file defines the chunk size and provides some means of clock synchronization so that the player has a chance to stay in sync with the server.

HLS is a fairly basic protocol and that’s pretty much all there is to it.  It’s supported natively by Safari and iPhone/iPad/i-Devices.  That means, it is supported by those browsers directly with no additional wrapper required.  Other browsers and Android Devices must use JavaScript to run HLS — more on that in a moment.

DASH is a more extensive protocol and its playlist can do all kinds of crazy crap.  DASH is natively supported by extremely few devices (Some random Android-based stuff mostly); everything else uses JavaScript or Flash to process DASH.

JavaScript is what is used to make dynamic web pages, and it has many problems; the biggest of which is that it is slow, and the second biggest is that it can use a lot of resources on the device it’s running. This is fine for web pages, but it isn’t really built to be “real time”. In fact, JavaScript heavy applications tend to be a lot laggier than their static counterparts.

Tigerdile, for the record, uses HLS because it is simpler and we have a lot of i-Device users — it makes sense to cater to the i-Devices as a result. DASH is just not really well supported yet and I couldn’t even get it to work, period, in my test cases.

Anyway, so what’s the big problem?  The problem is synchronization.  Because both DASH and HLS are basically hacks that ride on top of a relatively cumbersome document protocol (HTTP), serving real time video is not what any of this stuff is made for.  If something falls out of sync, or your browser isn’t able to download the files from the server fast enough, then the stream will “stall”.  It will just freeze and never come back until you refresh the page.

The other problem is that, because we’re serving a series of static video slices, the viewer has to wait for the static video slices to accumulate.  That’s why there’s a built in delay; these video slices have to be made and then kept lying around for when viewers show up.  The viewer has to download the slices before they expire and get deleted; in order to minimize the chance of a slice not being there (and thus stalling), the server has to keep more slices which mean the viewer just gets further behind.  The viewer will, at a minimum, always be a couple slices behind the live stream which is why there is a baked in delay of 10 – 30 seconds based on server configuration.

RTMP is less likely to do that, because its made to try and solve these problems.  In the future, HLS and DASH may minorly improve — however the basic concept of a series of static videos is a terrible one.  It feels like some guys had a kegger and said, “Hey, I got this one — here’s how we make a live stream!”  Yeah, great guys, real great.  What we really need is for browsers to natively support an RTMP-like but free (not owned by Adobe) protocol.

I’m not holding my breath for that to happen. In the meantime, Tigerdile streams will default to using Flash and fall back to HLS only if Flash is not available. We continue to recommend using Flash for stream viewing.

 

– Tanabi Goat, cantankerous programmer type

 

P.S. Your individual experiences with streaming protocols will vary.  Please do not send support a bunch of mails saying “well, that’s not how it works for me” or “this other service does it better!”  Though if you do have constructive, technical feedback to help us improve, your input is welcome! Or if you’re having a problem with Tigerdile that you would like us to look at, let us know — that is ALWAYS welcome and encouraged!