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?
Best Answer
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
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.