18

I'm working on a website that needs to stream live video to users, and as such I've had to get my head around the sorry state of current browser-based video-streaming technology. The most popular solutions for live streaming at present all have compatibility issues; RTMP requires Flash, HLS is only natively supported on Safari and Chrome for Android, DASH isn't natively supported anywhere, and using dash.js requires Media Source Extensions, which aren't yet widely supported.

This leads to a question that to me seems obvious: is it possible to use simple progressive download as an alternative to protocols like HLS, RTMP and DASH that either require browser support or plugins?

The idea of using progressive download to stream live media isn't unprecedented; people already do it for audio. Tools like liveCaster allow you to stream live MP3 audio through a single progressive HTTP response without needing a pre-recorded MP3 file, and libraries like AmplitudeJS have gone out of their way to add features related to this kind of live audio streaming.

I haven't seen any instances of this technique being used in the wild for video, though, and I can't tell why. It seems like it would remove a layer of messy and difficult browser-side compatibility problems for relatively little tradeoff. (And compatibility is still a huge problem for live streaming, even when the pros do it; if I try to watch live video on BBC's iPlayer in Firefox, it just gives me an error message telling me to install Flash.) Yet nobody is using this technique, and I've never seen anybody even mention the idea besides me.

Why? Is there a fundamental limitation I'm not seeing that would make it impossible just stream a video file like an MP4 via progressive download as it is being generated, and play it in a <video> element as it downloads?

Mark Amery
  • 1,241
  • 13
  • 27
  • Couldn't you use an HLS javascript library (e.g., hls.js here: https://github.com/video-dev/hls.js/tree/master) to add cross browser HLS support for your page? I guess this perhaps didn't exist when you asked this question originally...but, it does now. :) – stuckj Sep 15 '17 at 14:56

1 Answers1

3

Your question is valid and theoretically I think you can use Progressive Downloads for live video streaming. Actually A lot of Online Streaming Video like YouTube etc already use HTTP. I am assuming you are strictly talking about LIVE streaming and not just streaming.

You will have to implement the Live Streaming use cases though, yourself! Which otherwise the streaming protocols (RTMP etc.) do themselves. Here are some reasons to prefer these protocols and architecture:

1. Variable Bit Rate

Most Live streaming video is encoded in VBR and your video will have to quickly adapt to changing network congestion of your client. So your video can go switch multiple resolutions in a very short time depending on how fast or slow the client connection is.

According to Wikipedia

It works by detecting a user's bandwidth and CPU capacity in real time and adjusting the quality of a video stream accordingly

2. Live Content

The most important point is that Live streaming means live content. Unlike HTTP Progressive Download, you cannot buffer at any time. The user must see the latest frame intended for the whole world and cannot lag behind.

3. Disable Seeking

A minor issue, but the protocol should specifically not allow the user to seek backwards (and obviously forwards). This shouldn't just be controlled at the Video Player level but also at the network level.

4. Frequent disconnections / unreliable network

I am a bit unclear about this point but I do know that once an incoming HTTP download is disconnected, it can take some time to establish another handshake (even with keep-alive). Live protocols are much faster to connect and disconnect because of the next point ->

5. Latency

HTTP inherently runs over TCP which is gives guaranteed delivery of packets. Compare this with UDP used in a lot of protocols (especially live multiplayer gaming) where speed is prioritised over guarantees.

For more see here -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Content Copying

Most live stream servers will only respond to the current time's content. Though it is still possible to copy content of live streams, one has to resort to screen capture etc. Giving an HTTP progressive download makes the task of copying content quite trivial (Hence so many many YouTube downloaders out there).

Now, HTTP can be modelled to provide most of the above.

Apple's HTTP Live Streaming (HLS), you mentioned, comes closest to what you're trying to achieve.

And there is active research going on in this field as given here -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

I'm on the lookout for more info and will update this answer.

Gaurav Ramanan
  • 624
  • 3
  • 8
  • It seems incorrect to mention latency as a *disadvantage* of using HTTP progressive download given that the primary competitors include DASH and HLS which deliver segments of video via multiple sequential HTTP requests. I don't know every detail of the protocols, but I'd assume that the latter approach *requires* a minimum latency of at least the segment length being used, whereas with the progressive download approach there is no theoretical minimum latency - lower latency should be an *ad*vantage of the progressive download approach, right? – Mark Amery Oct 06 '15 at 14:27
  • Also, some of the other concerns here - like seeking and recovering from disconnects - are problems that apply equally to a JavaScript implementation of DASH, yet dash.js presumably overcomes them. I imagine they could be overcome for a progressive download player just by stealing whatever solutions the dash.js developers have come up with. – Mark Amery Oct 06 '15 at 14:31
  • @MarkAmery If you compare to DASH and HLS then yes I guess its comparable. But, if you compare it with some of the older protocols that's over UDP then HTTP loses hands down! Even if you see a lot of realtime systems today are built using Websockets and eschew HTTP because of its latency issues. – Gaurav Ramanan Oct 06 '15 at 14:32
  • 1
    Ease of content copying is a real disadvantage over dash.js and HLS, though. And I'm not sure how variable bit rate streams could be implemented using progressive download, although I expect it would be possible with a little cunning. – Mark Amery Oct 06 '15 at 14:33
  • @MarkAmery When it comes to realtime and live streaming, we must consider **performance** and not just possibility. I'll look into DASH but I wonder if there are benchmarks that show performance comparisons between Streaming Protocols and HTTP recovering from a disconnect. – Gaurav Ramanan Oct 06 '15 at 14:34
  • As far as UDP goes - sure, UDP-based protocols like RTMP are probably superior performance-wise, but that's of little use to you if you're developing a browser-based client, since JavaScript doesn't give you any way of using UDP. *Flash* does, but if you've got Flash available to you, you're probably better off using RTMP anyway (which is TCP-based, not UDP-based). My motivation for considering progressive download solutions was to increase browser compatibility - anything that needs UDP defeats that objective immediately. – Mark Amery Oct 06 '15 at 14:38
  • @MarkAmery Let me clarify, I am definitely *with you* on this. I would implement an HTTP based protocol with JS. Based on the links I gave I guess so is the rest of the tech world! I'm just playing Devils advocate here & listing a few functionalities these older protocols *can*implement. I think recreating these in HTTP is one of the major reasons for major incompatibilities. It was expected that Apple would make HLS a standard by submitting to IETF but I'm not surprised they haven't! One of these companies has to pioneer a standard which will lead to cross platform goodness! – Gaurav Ramanan Oct 06 '15 at 14:45